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

In this chapter I describe the sprint review—its purpose, its participants, and the work required to make it happen. I conclude by addressing a few common sprint review issues.

Overview

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 (see Figure 21.1).

Figure 21.1. When the sprint review happens

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.

Because it helps ensure that the organization is creating a successful product, the sprint review is one of the most important learning loops in the Scrum framework. And, because sprints are short, this loop is a quick one, which allows for frequent course corrections to keep the product development moving in the right direction. If, instead, we were to defer this feedback until much later and assume that everything is going according to some baseline plan, we likely would get what many are accustomed to—surprise, disappointment, and frustration.

Participants

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, as summarized in Table 21.1.

Table 21.1. Sprint Review Attendee Sources

All Scrum team members (product owner, ScrumMaster, and development team) should be present at every sprint review so that they can describe what has been accomplished, answer questions, and enjoy the benefits of firsthand feedback.

Internal stakeholders, such as business-area owners (who may be paying for the system being built), executive management, and resource and other managers, should also attend. Their feedback is essential to ensuring that the team is progressing toward an economically sensible outcome. In addition, sprint reviews provide a convenient opportunity to learn the status of the product development effort. Also, for internal development efforts, the users will be internal to the organization; a representative sample of these users should attend along with subject matter experts who are an excellent source of feedback on what has been built.

Others in your organization might want to attend as well. Salespeople and marketing specialists frequently sit in. They can be an excellent source of feedback on whether the product is converging on a marketplace success. Other groups, such as support, legal, and compliance, might also come to sprint reviews to stay abreast of the team’s progress, to provide timely input to the team, and to better gauge when to start their own related work.

Other internal development teams on related development efforts might send representatives so that they can ascertain where the product is headed and provide any relevant input on what they are doing and how it might impact the current development effort.

It’s a good idea to at least periodically include external stakeholders, such as actual customers or users of what the team is building. With them in the room, the team can get direct feedback instead of indirect (or proxy) feedback via internal stakeholders. It may not make sense to have external stakeholders at every review, especially if we know that a particular review might involve some intense internal discussions that are best conducted with internal stakeholders only. If we do choose to include external stakeholders, unless there is just a single stakeholder, some consideration should be given to which of the potentially many customers or users we should invite. Common sense as well as sensitivity to the desires and personalities of specific people should be good guides on whom to invite.

Prework

Although the sprint review is an informal activity, the Scrum team has some minimal prework to complete (see Figure 21.2).

Figure 21.2. Sprint review prework

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

Determine Whom to Invite

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.

If you suspect these situations might arise, identify a core group that should be invited to every review and then issue a separate invitation to certain groups or clients on a sprint-by-sprint basis.

Schedule the Activity

The sprint review needs to be scheduled (when, where, and how long). Of the four required, recurring Scrum activities (sprint planning, daily scrum, sprint review, and sprint retrospective), the sprint review is the hardest to schedule because it includes many people who are outside of the Scrum team. The other three recurring activities involve only people on the Scrum team and therefore can be scheduled at its convenience alone.

To make scheduling easier, begin by determining when the key stakeholders (the core group I mentioned earlier) would prefer to hold the sprint review—say, Friday afternoons at 2:00 p.m.—and then schedule the rest of the sprint activities around this fixed time. If, as I discussed in Chapter 4, we use consistent-duration sprints (say, every two weeks), we can then schedule all, or at least most, of the sprint review meetings using a regular cadence (every second Friday at 2:00 p.m.). This has the dual benefit of reducing the administrative burden and costs while increasing attendance.

Sprint reviews vary in duration depending on several factors, including sprint length, team size, and whether multiple teams are participating in the same review. Typically, however, the sprint review does not exceed a four-hour timebox. Many teams have found the one-hour-per-sprint-week rule helpful. In other words, for a two-week sprint the review should take no more than two hours; for a four-week sprint it should take no more than four hours.

Confirm That the Sprint Work Is Done

At the sprint review, the team is allowed to present only completed work—work that meets the agreed-upon definition of done. (See Chapter 4 for more on this topic.) 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. As I mentioned in Chapter 9, the 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.

Not everyone agrees that the product owner should review the work before the sprint review. Some practitioners contend that the product owner should review and formally accept the work only during the sprint review. They believe that if the product owner is allowed to review the work during the sprint, he might request changes that go beyond clarification—goal-altering changes that will disrupt sprint execution (see Chapter 4).

This is a potential risk, but the benefits of early product owner reviews (fast feedback) far outweigh any downside. Furthermore, if the product owner sees the team’s work for the first time at the sprint review meeting, he has seen it too late. Here’s why. The product owner must be available during sprint execution to answer questions and clarify product backlog items. While fulfilling these obligations, the product owner should also review the ongoing progress the team is making and provide critical, in-flight feedback that can be acted on in a timely, cost-effective manner. Deferring this feedback until the sprint review would create unnecessary work and likely frustrate the team (“Why didn’t you mention that during the sprint, when we could have fixed it easily?”). It also could potentially irritate the stakeholders (“This feature would have been potentially shippable if you had just handled those things during the sprint!”).

Beyond this, however, a product owner who rejects or questions work during the sprint review might not appear to be on the same page as the rest of the Scrum team. That disconnect could come across to the stakeholders as the old, adversarial, us-versus-them problem. The product owner and development team are on the same Scrum team and should come across as one unified team during the review meeting.

Prepare for the Demonstration

Beause 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 goal is to provide transparency for inspecting and adapting the product, not to put on a glitzy Hollywood production or showcase to create excitement.

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. I would be thinking, “Are these guys really done? Why won’t they just show me what they created?”

Most teams have a rule of not spending more than 30 minutes to an hour per week of sprint duration to prepare for the sprint review. In addition, many also agree to show only those artifacts that were produced as a consequence of achieving the sprint goal.

Of course, there can be exceptions to the rule. I worked with an organization that developed systems under a U.S. Army contract. Most of the time, government employees (from the bureaucratic ranks) would attend the sprint reviews. Occasionally, however, the U.S. general in charge would be scheduled to attend a sprint review. In those cases, the team understandably invested a bit more time in prep and polish!

Determine Who Does What

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 ScrumMaster 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. However, I try to not get too wrapped up in who is going to do these things. I let the Scrum team make that determination with a goal of maximizing the benefit of the review activity.

Approach

Figure 21.3 illustrates the sprint review activity.

Figure 21.3. Sprint review activity

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.

Summarize

The sprint review kicks off with a Scrum team member (frequently the product owner) presenting the sprint goal, the product backlog items associated with the sprint goal, and an overview of the product increment that was actually 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 Scrum team provides an explanation. It is important that the sprint review be a blame-free environment. If the goal wasn’t met, everyone participating should refrain from trying to assess blame. 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

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.

As determined in the prework, one or more Scrum team members will demonstrate all relevant aspects of the product increment that was built during the sprint. In certain organizations, such as game studios, it can be even more effective to let the stakeholders actually give themselves the demo, perhaps by playing the increment of the game that was developed during the sprint.

But what if there is nothing to demo? If the team didn’t get anything done and there is truly nothing to show, the sprint review will likely focus on why nothing got done and how the future work will be affected by the lack of progress during this sprint. If, on the other hand, what was built can’t easily be demoed, we have a different issue. Suppose, for instance, that the team did only architectural development work this sprint (built “glue code”). In that case, the development team might argue that demonstrating glue code doesn’t make any sense or isn’t practical. This statement, however, is almost never true. Here’s why.

For the team to work exclusively on “glue code,” it would have needed to convince the product owner to allow only technical product backlog items into the sprint. As I discussed in Chapter 5, if the product owner allows such items, he must understand the value of doing the work and also must know how to determine if the work is done. Also, most teams will include in their definition of ready that the Scrum team understands how to demonstrate the item at the sprint review.

At a minimum, the team must have some set of tests to demonstrate that the work is done to the satisfaction of the product owner. Those tests must have passed because the team can show only completed work at the sprint review. So, at the very least, the team can use those tests to demonstrate at the sprint review. Usually, though, if the team members give it some thought, they can do much better. The fact that something is hard to demo is not a valid excuse to exclude it from the demo.

Discuss

Demonstrating the product increment becomes the focal point for having an in-depth conversation. 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.

Vigorous discussion allows participants who aren’t on the Scrum team to ask questions, understand the current state of the product, and help guide its direction. At the same time, the Scrum team members gain a deeper appreciation for the business and marketing side of their product by getting feedback on the convergence of the product toward delighted customers or users.

Adapt

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.

I described in Chapter 6 how most teams naturally do some grooming as part of the sprint review. As everyone involved gains a better understanding of the current development effort and where it is going, new PBIs are often created or existing PBIs are reprioritized or deleted if they are no longer needed. This grooming might affect what the team will work on in the next sprint.

Also, as I described in Chapter 18, the grooming that happens during sprint review might also affect the larger-scope release plans. For example, based on the discussion and conclusions of the sprint review, we might decide to alter one of the key release-planning variables: scope, date, or budget. Perhaps, for instance, by reviewing the current product increment we decide to stop working on a major feature of the product (change the scope). This decision will necessarily affect the current release plan.

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.

Sprint Review Issues

Sprint reviews, however, are not without issues. Having worked with many organizations using Scrum, I have 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 previously, before the sprint review even begins, the product owner must review the work to determine if it is done (meets the agreed-upon definition of done). The sprint review, therefore, should not be a formal approval or sign-off event; instead, the product backlog items should have already been “approved” by the product owner before the sprint review starts.

Let’s say, however, that during the sprint review a senior-level stakeholder disagrees—he believes the product backlog item is not done. While that feedback is valuable, I would still say that if the product owner declared the original work done, it is done. In Chapter 9 I discussed how the product owner has to be the empowered central point of product leadership. For this to be true, the product owner must be in a position to definitively approve or reject work and can’t have that authority usurped by a sprint review participant—no matter how senior.

That doesn’t mean that 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 to insert that item into the product backlog to be worked on in a future sprint. The product owner should also investigate to determine why he disconnected from the stakeholders regarding this story and make adjustments to prevent future misunderstandings.

Sporadic Attendance

The sprint review needs to be viewed as a critical inspect-and-adapt activity, one that is worth people’s time to attend. Still, some organizations suffer from sporadic attendance.

One of the more common causes of sporadic attendance is that stakeholders have so much on their plates that other “higher-priority” commitments prevent them from attending sprint reviews. This is a strong indicator of organizational dysfunction—having so much concurrent work that stakeholders can’t meet all of their commitments. In such situations I recommend that organizations stop working on the lower-priority products until such time as they are important enough for stakeholders to attend sprint reviews. If that day never arrives, those low-priority products, relative to the other products in the portfolio, are simply never valuable enough to work on.

Sometimes sporadic attendance is the result of people not believing that the Scrum team can produce anything worth reviewing in a few weeks’ time. This is especially true when the organization first starts using Scrum. Stakeholders are accustomed to much longer periods between reviews, and the reviews they have attended heretofore might have been disappointing.

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 realize that these frequent reviews are worth their time and allow them to give fast feedback that the Scrum team can actually use.

Large Development Efforts

If you have a larger development effort with multiple Scrum teams, it might make sense to consider doing a joint sprint review. This is simply a review that includes the work completed by multiple highly interrelated teams.

There are several benefits to this approach. First, the stakeholders have to attend only one sprint review instead of several. Second, if the work was supposed to be integrated, it would make sense for the review to focus on the integrated work, not a collection of stand-alone increments. To achieve this goal, all teams need to make sure their definitions of done include integration testing, as they probably should anyway.

The downside to holding a joint sprint review meeting with more than one team is that it will probably take a bit longer and might require a larger room than any one team would have needed.

Closing

In this chapter I emphasized the purpose of the sprint review as a critical feedback loop during Scrum development. The sprint review involves a diverse set of participants, whose goal is to inspect and adapt the current product. Although the sprint review is an informal activity, the Scrum team does do minimal preparation to ensure a healthy, productive outcome. During the sprint review the Scrum team provides a synopsis of what took place and what was accomplished during the sprint. It also provides a demonstration of the product increment produced during the sprint. A vigorous discussion among the participants takes place; questions, observations, and suggestions are highly encouraged. Based on this discussion, the product backlog will be groomed and the release plan updated.

In the next chapter I will focus on the inspect-and-adapt activity for the process, the sprint retrospective.