Sprint Review & Retrospective
Timing for Sprint Reviews & Retrospectives
Each sprint ends with a sprint review and sprint retrospective. Both of these components occur on the last day of the sprint. The sprint review is focused on the product increment created during the sprint. It starts with a customer review and demonstration and ends with discussion and updates to the product backlog and release plan. The sprint retrospective is focused on how the team worked together during the sprint.
The duration of the meetings vary. For each week of sprint duration, apply one hour of meeting time for the sprint review. For the retrospective, apply .75 hours (45 minutes) for each week of sprint duration. For example, a 30-day sprint would result in a four-hour review and a three-hour retrospective. A two-week sprint would result in a two-hour review and a one-and-a-half hour retrospective. Additionally, the team should spend no more than one hour preparing for the review.
Elements of the Sprint Review
The sprint review occurs on the last day of the sprint. The purpose of the meeting is for the team to show the customers and stakeholders the work they have accomplished over the sprint so that the entire Scrum team can receive feedback to fine-tune the product backlog and release plan. The meeting is facilitated by the product owner but it is not uncommon to have the team members run the meeting. The customers should be reviewing the following data:
- The work the team committed to delivering
- The work they completed
- Key decisions that were made during the iteration/sprint (this may include technical, market-driven, requirements, etc, and can be decisions made by the team, the product owner, the customers, or anyone else)
- Project metrics (code coverage, etc)
- Demo of the work itself (this should be the vast majority of the meeting)
- Priority review (for the next iteration/sprint)
Most agile teams will ask customers to accept the work right then and there; after all, it meets the definition of done and should be potentially releasable at this point. Some customers, however, want time to use the application before pushing it out, so some teams opt to give their customers up to a week to formally accept the work. It is very important to get acceptance – don’t skimp on this.
Running a Sprint Retrospective
The sprint retrospective also occurs on the last day of the sprint, typically immediately following the sprint review. The purpose of the retrospective is to identify the things that the team is doing well that they should keep doing; things they should start doing in order to improve; and things that are keeping them from performing at their best that they should stop doing. The meeting is facilitated by the ScrumMaster; the product owner is typically not in the room.
This is a very important meeting. To reach a high performing state, teams have to continually work to reinforce good patterns of behavior and eliminate bad patterns. Skimping on this meeting will cause the team to, at best, perform at sub-optimum levels and, at worst, bring the whole process to a grinding halt.
For more on running effective sprint retrospectives, please read the blog post, Well-Run Retrospectives for Scrum and Agile Teams. For an in-depth guide to retrospectives, consider these books: _Project Retrospectives: A Handbook for Team Reviews _by Norm Kerth and _Agile Retrospectives _by Esther Derby and Diana Larsen.