Agile Development: Sprint Review

At the boundary between sprints, there are three different tasks that an Agile team should perform:

1. Review and demo the work completed in the finished sprint (Sprint Review)
2. Plan the next iteration (Sprint Planning)
3. Evaluate the team’s performance during the sprint and look for improvements (Sprint Retrospective)

While it may be tempting to package that entire list into one long meeting, these should really be separate sessions. Each one requires a different focus and a unique cast of characters; plus, meetings can only last so long before efficiency plummets. Over the next set of posts I will be discussing each of these tasks separately, in the order in which I listed them. Even though planning happens first in any particular sprint, I prefer to look at the transition between sprints as a single process. So, we’ll start with Sprint Review.

Objective

As we’ve discussed previously, one of the core values of Agile is to prioritize working software; an Agile team should deliver a potentially shippable product at the end of each sprint. This approach increases flexibility (each new sprint is an opportunity to begin with a clean slate and completely change direction if necessary), and forces the entire team (on both the technology and business sides) to optimize feature design. Therefore, at the end of every sprint, the team should be able to demo a new piece of working software, and that is indeed what the focus of the Sprint Review meeting should be.

Participants

This should be the most crowded meeting out of the three; it should be open to all project stakeholders. The development team should attend and be ready to demo their product. This should be an informal presentation, focused on the software itself rather than presentation slides or backlog lists. A more formal approach would take the focus away from the product itself, and it would mean unnecessary prep work for the developers. The team knows what they built, and they should present that to the rest of the participants.

The Product Owner will be there to compare the completed product to the predefined sprint goals, but the focus should be on whether the software fulfills user needs, rather than checking off assigned tickets. The team may have found a better way to solve the problem during the sprint, and the Product Owner would have been consulted at that time, so there should be no surprises.

The demo should also include the Scrum Master, organization management, customers (if possible), and anyone else who is invested in the success of the project. Developers from other teams should be allowed to attend if desired, as a way to promote cross-team communication and organizational knowledge sharing.

Meeting Agenda

The Product Owner should begin the meeting by briefly articulating the sprint goals and providing context for attendees. Again, this shouldn’t be a big formal presentation. Sprints typically only last 1-3 weeks, so no one should be taking up valuable hours getting ready for a review meeting. Each participant is only asked to talk about her specific areas of expertise, so she should be able to almost improvise her remarks.

Next, the development team will demo the completed work, within an environment that mimics production as closely as possible. If the object of the sprint is to produce releasable software, the demo should feel as if the software has been released, so the audience can get a feel for the true user experience. Hard-coded constants and mock-ups should be used minimally, if at all.

Next, the audience should ask questions and offer feedback on the demo, followed by the Product Owner describing next steps and goals. The purpose of this meeting is not for the Product Owner to approve completed work, or for the development team to share their work with one another; that will have happened during the course of the sprint. It is for the PO and the development team to showcase their work and receive feedback on whether the product fulfills the needs of the user.

If you want to learn more about sprint review meetings, you can check out the following resources:

• Mark Layton’s article on the basics of the sprint review.
• An entertaining presentation from the folks at Scrum Training Series.
• Ron Quartel’s exploration of common Sprint Review misconceptions.

I’ll be back next month to discuss sprint planning.

What are your thoughts on how your organization implements sprint reviews? Who should (or shouldn’t be present a sprint review demo? What do you do about work that has not been completed by the end of the iteration?

“BIS-Sprint-Final-24-06-13-05” image By Birkenkrahe (Own work) [CC BY-SA 3.0 (http://creativecommons.org/licenses/by-sa/3.0)], via Wikimedia Commons