Sprint Report

At the end of every sprint, it is important for teams to reflect upon and learn from their experience. This provides a chance to think about how to improve the team's process, and to develop a consensus understanding of what happened over the previous sprint.

The Sprint Retrospective meeting is where teams perform this reflection. This meeting is held right after the end of a sprint, and before planning for the next sprint begins. During this meeting, teams should answer the following questions:

What things should we stop doing?

These are actions and activities the team did over the previous sprint that hurt the team, in the sense that they made the team go slower, or perform lower quality work. These are practices that the team would like to stop. Note that required software process elements (three times weekly daily scrum meetings, sprint burndown charts, sprint reports, weekly team status reporting, etc.) are mandatory items. They're off the table for activities the team should stop doing.

What should we start doing?

These are actions or activities the team should start doing in the next sprint, because there is a strong expectation they will improve how the team does its work. That is, what should the team do to improve how it works? Especially if a team has not completed all of its tasks during the previous sprint, changes in work practices need to be made to ensure this will not occur in future sprints.

What is working well that we should continue to do?

These are work practices and activities that the team generally thinks were a benefit, and helped the team do good work. After the first sprint, it is useful to go through and identify all work practices that worked well, to ensure the team agrees, and to reinforce these good practices. Beyond the first sprint, this question usually focuses on whether new changes introduced during recent retrospectives should be continued.

What work was completed, and not completed?

This is a list of all user stories that were completed during the previous sprint, and a list of all user stories that were in the sprint plan for the previous sprint, and were not accomplished.

What is our rate of completing work?

After each sprint, a team should add up how many story points (from user stories) and how many ideal work hours (from tasks) it was able to complete during the sprint. The team should then divide these numbers by the number of days in the previous sprint to develop actual rates of work completion (story points/day) and (ideal work hours/day). These should then be combined with previous work rates from prior sprints to compute average work rates (across all sprints). This will yield average story points/day and average ideal work hours/day figures. Finally, the team's final sprint burndown chart comprises part of this report (scan or take a photo of the final burndown chart, and include it in the report.)

This then gives your team a sense of its capacity to perform work, and should be used as the starting point for estimating how much work can be performed during the following sprint. These rates might also lead to reflection. If the team was much slower or much faster than average during the previous sprint, the team should understand why this occurred.