Each sprint ends with a two-part sprint review meeting. This four-to-eight hour meeting (depending, again, on sprint length) starts with a two-to-four-hour customer review and demonstration and ends with the two-to-four-team retrospective. Both of these components occur on the last day of the sprint. The team should spend no more than one hour preparing for the review.
Customer Review (or Demo)
The customer review meeting 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. The meeting is facilitated by the product owner but it is not uncommon to have the team members run the meeting. In this 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 iterationsprint (this may include technical, market-driven, requirements, etc, and can be decisions made by the team, the CRproduct owner, the customers, or anyone else)
- Project metrics (code coverage, etc)
- Demo of the work itself
- Priority review (for the next iterationsprint)
Most agile teams will ask customers to accept the work right then and there; after all, it is potentially shippable 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.
The duration of the customer review meeting varies depending on sprint length. For a one-week sprint, the meeting should last about thirty minutes; for a two-week sprint, an hour. Teams running four-week sprints should allow two hours for this meeting.
Team Retrospective
The team retrospective also occurs on the last day of the sprint, typically after the customer review meeting. The purpose of the team 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 and the Product Owner is typically not in the room.
This is a very important meeting. Just as a car needs to get its oil changed every 3,000 miles, the team needs its oil changed regularly too. The retrospective provides just that, an oil change – drain out the goop and bring in some good stuff – or at least develop a plan on how to start removing the metaphorical sludge from the team’s system. After all, the bad habits we have developed over the years are not going disappear with the wave of a magical wand. 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.
Like the other meetings, how much time to budget for a team retrospective meeting depends on sprint length. For a one-week sprint, the meeting should last around forty-five minutes, for a two-week sprint, about ninety minutes, and for a four-week sprint, as many as three hours.
For more on running effective team retrospectives, please read Project Retrospectives: A Handbook for Team Reviews by Norm Kerth and Agile Retrospectives by Esther Derby and Diana Larsen.