Sprint Review

Near the end of the Sprint, the team conducts two important inspect-and-adapt activities: the Sprint Review and the Sprint Retrospective. The Sprint Review focuses on the product itself. The Sprint Retrospective, on the other hand, looks at the process the team is using to build the product.

During Sprint Planning we plan the work. During Sprint Execution we do the work. During Sprint Review we inspect (and adapt) the result of the work – the Potentially
Shippable Product Increment. The Sprint Review occurs near the end of each Sprint cycle, just after Sprint Execution and just before – or occasionally after – the Sprint Retrospective.

The Sprint Review gives everyone with input to the product development effort an opportunity to inspect and adapt what has been built so far. The Sprint Review provides a transparent look at the current state of the product, including any inconvenient truths. It is the time to ask questions, make observations or suggestions, and have discussions about how to best move forward given current realities.

Demonstrates what was achieved in the Sprint and collect feedback
Whole team participates
Invite anyone and everyone

The Sprint Review provides an important opportunity for the Scrum Team to get feedback from people who typically are not available on a daily basis during Sprint Execution. For these individuals, the Sprint Review is their first opportunity to see and discuss the work that was produced during the Sprint. The Sprint Review, therefore, should be attended by all interested parties, who can come from a number of different sources.

sprintreviewattendees

Although the Sprint Review is an informal activity, the Scrum Team has some minimal pre-work to complete. This pre-work includes determining whom to invite, scheduling the Sprint Review, confirming that the Sprint work is done, preparing for the Sprint Review demonstration, and deciding who will lead the meeting and who will give the Demo.

The Scrum Team first needs to determine who should attend the Sprint Review on a regular basis. The goal is to get the right set of people into the room to extract the highest possible value. Unless there is a good reason to not invite someone or some group, cast a broad net and let people vote with their feet – if they’re interested, they’ll walk to the room and attend the meeting. Occasionally, the team might need to constrain attendance. For instance, the team might need to focus on a certain person or group whose input is essential to reviewing this sprint’s work. Or the team might be building a feature for a specific client during this sprint and so cannot invite that client’s competitors to the review meeting.

At the Sprint Review, the team is allowed to present only completed work – work that meets the agreed-upon Definition of Done. This implies, then, that sometime before the Sprint Review, someone has determined whether or not each backlog item is done; otherwise, how would the Scrum Team know which items to present? Ultimately it is the Product Owner’s responsibility to determine if the work is done or not. Product Owner should be performing just-in-time reviews of Product Backlog Items as they become available during Sprint Execution. This way, by the time the Sprint Review happens, the team knows which items are complete.

Because all of the work the team presents at the Sprint Review is done – Potentially Shippable -, it shouldn’t take much preparatory work to demonstrate it. The Sprint Review is supposed to be an informal meeting with low ceremony and high value. Spending a lot of time to create a polished PowerPoint presentation hardly seems justified. Also, I would be concerned if I showed up at a Sprint Review to see working software and instead was given a PowerPoint presentation.

Prior to the Sprint Review, the team needs to decide who on the Scrum Team is going to facilitate the review and who will demonstrate the completed work. Typically the Scrum Master facilitates, but the Product Owner might kick things off by welcoming members of the stakeholder community and providing a synopsis of the Sprint results. As for demoing the completed work, I prefer that every member of the Development Team have an opportunity at some sprint review to go hands-on and demonstrate, rather than the same person always dominating the demo every sprint review.

The inputs to the Sprint Review are the Sprint Backlog and/or Sprint Goal and the Potentially Shippable Product Increment that the team actually produced. The outputs of the Sprint Review are a groomed Product Backlog and an updated release plan. A common approach to conducting the Sprint Review includes providing a summary or synopsis of what has and has not been accomplished with regard to the Sprint Goal, demonstrating the Potentially Shippable Product Increment, discussing the current state of the product, and adapting the future product direction.


sprintreviewactivity

The Sprint Review is frequently mislabeled the “Sprint Demo” or just “the Demo.” Although a demonstration is quite helpful in the Sprint Review, the Demo is not the aim of the Sprint Review. The most important aspect of the Sprint Review is in-depth conversation and collaboration among the participants to enable productive adaptations to surface and be exploited. The demonstration of what actually got built is simply a very efficient way to energize that conversation around something concrete. Nothing provides focus to the conversation like being able to actually see how something works.

Observation, comments, and reasonable discussion regarding the product and direction are strongly encouraged among the participants. The Sprint Review, however, is not the place for deep problem solving; that type of work should be deferred to another meeting. Through demonstration and discussion, the team is able to ask and answer questions, including the following:

  • Do the stakeholders like what they see?
  • Do they want to see changes?
  • Is what we’re building still a good idea in the marketplace or to our internal customers?
  • Are we missing an important feature?
  • Are we overdeveloping/investing in a feature where we don’t have to?

Asking and answering these questions provides input on how to adapt the Product Backlog and release plans. The Sprint Review gives us an opportunity to identify ways to adapt, to respond to change, when it is still affordable to do so – at the end of every single Sprint.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s