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 varies. 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 developers or delivery people 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.

Here’s a tip: I will only do a Sprint Review for one-hour in a two-week Sprint, as I find my stakeholders don’t want to be in a two-hour meeting. This forces the Scrum team to be really focused and ready for the meeting.

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 Scrum Master; all Scrum Team members should be present and participating, including the Product Owner.

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 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.