Chapter 21: Sprint Review

Near the end of the sprint, the team conducts two important inspect and adapt activities: the sprint review and the sprint retrospective. This chapter focuses on the sprint review.

Sprint Review Overview

The sprint review is the time when the Scrum team invites its stakeholders to give feedback on the product itself. Recall that during sprint planning, the team planned the work. During sprint execution, the team did the work. And now, in the sprint review, the team inspects the result of the work—the potentially shippable product increment.

Sprint Review Timing

The sprint review occurs near the end of the sprint, just after sprint execution and just before the sprint retrospective. In most cases, a sprint review should take no longer than four hours. Many teams find the one-hour-per-sprint-week rule helpful. In other words for a two-week sprint, the team should limit the review to no more than two hours; for a four-week sprint, no more than four hours.

Sprint Review Participants

The sprint review is an excellent 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 invitation list for the sprint review, therefore, should include all interested parties.

The entire Scrum team (development team, ScrumMaster, and product owner) should attend. Other potential attendees include internal stakeholders (e.g., internal users or subject matter experts) other internal teams (e.g., marketing or support), and even external stakeholders (e.g., external customers or partners).

Sprint Review Prework

Although sprint reviews are informal by design, the teams should do some minimal prep work.

• Invitations. The team must determine who to invite. The list is likely to vary somewhat from sprint to sprint depending on the work accomplished during the sprint.
• Scheduling. The sprint review should be scheduled around the availability of a few must-have stakeholders. Ideally, this day and time could be fixed for all of the sprints, so that it occurs at a regular cadence. Remember that the sprint review should be timeboxed, and typically takes somewhere between 2 and 4 hours depending on sprint length.
• Confirmation. The team can only present completed work at the review, so sometime before the sprint review, the team must ensure that the work is indeed done. I recommend having the product owner review the work and sign off on it prior to the sprint review. That way, the product owner and development team are on the same page and can present a unified front during the review.
• Demo Prep. Because all of the work is done and potentially ready to ship, the team shouldn't need to do much to prepare to demonstrate it. Generally speaking, the goal is to provide transparency for inspecting and adapting the product, not to put on a glitzy Hollywood production. Many teams, therefore, have a rule where they will not spend more than an hour prepping the demo. Many also agree to only show those artifacts that were created as a consequence of achieving the sprint goal.
• Role Determination. The team needs to decide who on the Scrum team is going to facilitate the review (often, but not always, the ScrumMaster) and who is going to demonstrate the completed work. If it makes sense in your context, try to rotate the role of the demonstrator from sprint to sprint.

Sprint Review Approach

The inputs to the sprint review are the sprint goal, sprint backlog, and the potentially shippable product increment that the team actually produced during the sprint. The outputs are a groomed product backlog and an updated release plan. A common approach to conducting the sprint review is as follows: Overview (Summarize), Demonstrate, Discuss, and Adapt.

Overview (Summarize)

The sprint review kicks off with a Scrum team member (often the product owner) presenting the sprint goal, the product backlog items associated with that goal (often the sprint backlog), and an overview of the product increment that the team achieved during the sprint. This information provides a summary or synopsis of how the sprint results compare with the sprint goal. If the results don't match the goal, the team should provide an explanation. But it's important to keep in mind that a sprint review is a blame-free environment. The purpose of the review is to describe what was accomplished and then to use the information to determine the best course of action for moving forward.

Demonstrate

I want to take a moment to caution you about the term demo or sprint demo. Although a demonstration is frequently a quite helpful part of a sprint review, it is not the aim of the review. Read the blog post “It’s a Sprint Review Not a Sprint Demo!” for a deeper discussion of this topic.

The most important aspect of the sprint review is the in-depth conversation and collaboration among the participants. Through these interactions, the Scrum team surfaces and exploits productive adaptations. The demo is merely a way to jumpstart the conversation around something concrete.

Sometimes the team builds functionality that doesn't lend itself easily to a demo. That is not a valid excuse to exclude it from the demo. A team that gives it some thought, can always find a way to show stakeholders the work of the sprint.

Discuss

All sprint reviews should elicit vigorous discussion. Participants who aren't on the Scrum team should ask questions, understand the current state of the product, and help guide the product's direction with their feedback. The Scrum team should leave with a deeper appreciation for the business and marketing side of their product while getting feedback on the convergence of the product toward delighted customers or users.

As such, the sprint review is the perfect place to discuss observations, comments and feedback regarding the product and its current trajectory. It is not, however, the best venue for deep problem solving; that kind of work should be deferred to another meeting.

Adapt

Through demonstration and discussion, the Scrum team is able to ask and answer the following questions:

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

Common Sprint Review Issues

I've noticed several common sprint review issues, including those related to sign-offs, lack of attendance, and large projects.

Sign-offs

Sign-offs can be problematic in sprint reviews. The first question to ask is whether sprint reviews are the proper venue to sign off on (approve) product backlog items. As I mentioned earlier, the product owner should approve the product backlog items before the review even begins. Let's say though that, during the sprint review, a senior stakeholder disagrees and argues that a particular PBI is not done. While that feedback is valuable, I would still argue that the product owner's word on done or not done is final.

That doesn't mean the product owner should ignore comments about a feature not meeting stakeholder expectations. When this occurs, the proper course of action is to schedule a change to the feature by creating a new product backlog item to reflect the desired behavior requested by the senior stakeholder and then to insert that item into the product backlog to be work on in a future sprint. The product owner should also work to prevent future miscommunications.

Sporadic Attendance

Some organizations suffer from sporadic attendance at sprint reviews. One of the more common cause is that stakeholders are choosing other “higher-priority” commitments. This is a strong indicator of organizational dysfunction—having so much concurrent work that stakeholders can't meet all of their commitments. When this happens, I recommend stopping work on all lower priority products until they are important enough for stakeholders to attend the sprint review.

Other organizations see sporadic attendance because people don't believe the Scrum team can produce anything worth reviewing in a few weeks' time. The best way to address this issue is to actually build a business-valuable, potentially shippable product increment every sprint. When teams do this, most people come to realize that the frequent reviews truly are worth their time.

You can read more about sporadic attendence at the sprint review meeting in a series of blog posts starting with: “Stakeholders Missing at Sprint Reviews – Part One: Nothing to See Here.”

Large Development Efforts

If you have a large development effort with multiple Scrum teams, it might make sense to consider doing a joint sprint review. Joint reviews have several benefits. First the stakeholders have to attend only one sprint review instead of several. Second, if the work was supposed to be integrated, the review can focus on the integrated work rather than a collection of stand-alone increments. To achieve this goal, all the teams would need to make sure their definitions of done include integration testing, but they should probably do that anyway.

Downsides to joint sprint reviews might be that the meeting takes a bit longer or the meeting room needs to be bigger to accomodate more participants.

Closing

This chapter was focused on the sprint review, a critical feedback loop on the product during Scrum development. The next chapter will discuss the sprint retrospective, a Scrum practice focused on the process itself.