[Select Repost] Summarizing the Results of a Sprint
The end of an Agile sprint or iteration should be a relatively lightweight occasion. After all, it’s something that will be done at least once a month, and often much more frequently than that. So, it’s important that we don’t burden a team with any more process ceremony than necessary. Often a very simple sprint review is all that is needed. Read the blog post, Summarizing the Results of a Sprint, by Mike Cohn.
The end of an agile sprint or iteration should be a relatively lightweight occasion. After all, it’s something that will be done at least once a month, and often much more frequently than that. So, it’s important that we don’t burden a team with any more process ceremony than necessary. Often a very simple sprint review is all that is needed.
A Sprint Summary Document
Sometimes, though, as a ScrumMaster, I like to produce a sprint summary document. This short document contains very brief details of what work was done during the sprint, when the sprint was, who was on the team, any key decisions that were made during the sprint, and perhaps a few important metrics.
Audience
There are two target audiences for a sprint summary document. The first is any interested outsiders. This could include the VP of development, executives, stakeholders, department management, other teams and so on.
The second audience is future versions of the agile team itself. I’ve been in many situations where a team wanted to look back in time. A sprint summary can provide that view. Let me provide an example.
This one team was feeling depressed about how few automated tests they were writing. In the prior sprint, they’d added only about 200 total automated tests, which they knew was too low for what their system needed.
Because their ScrumMaster had been producing sprint summary documents, I retrieved a summary from six months earlier.
I shared with the team that they had once been struggling to write even one or two automated tests per sprint. (They were refactoring code so that it could support automated testing and were learning the concepts and tools.)
By sharing this information with the team from their sprint summary, I helped them realize how far they had come. Yes, they still had a long way to go, but they had already started moving the mountain, and momentum was now on their side.
Without a sprint summary document to provide exact facts, I would have had to rely on memory or had to piece things together by digging through the source code repository.
Content
While the specific contents of a sprint summary document are entirely up to you, there are a few things I’ve found to be helpful. These include ...
Context
Simply list the start and end date of the sprint and the number of working days in the sprint. I also list the people who were on the team, how many days each was expected to be available and the approximate number of days each was actually available.
The number of days a team member worked may differ from the planned days available because of illness or because the person was pulled onto another project mid-sprint, for example.
Metrics
Include any metrics here that are important to the ScrumMaster, stakeholders or the team. Keep it simple. I tend to include a graph or table of the velocity of the last 10 or so sprints (whatever horizon seems reasonable for your team). If you’re using burndown charts, include those.
You might also consider including things like the number of defects found or fixed, the number of automated tests added, code coverage, the number of builds deployed and so on.
If you are building the software for a client and need to report on cost, include things like billable hours and cost in this section.
But keep it simple.
Contents and Assessment
In this section, include a list of each product backlog item the team planned to do. Indicate whether the item was finished or not. And if the team estimates product backlog items (for example, in story points), include the size of the story.
Also include any additional notes from the sprint review on relevant decisions.
Finally, consider including a list of actions decided as a result of the sprint retrospective. This is entirely optional and be sure the team is OK including this. They may or may not be, depending on the audience for the sprint summary document.
Keep The Effort Short
Once you’ve produced an initial sprint summary document, you should find creating a new one for each sprint quite simple. My guideline is that it should not take more than 15 minutes per sprint to produce. If you keep the metrics section simple, this is quite feasible.
I’ve included a sample sprint summary document you can use to get started.