The value stream

The Sprint Review

At the end of each Sprint, the Scrum Team examines with its stakeholders what has been produced and decides what comes next. The Sprint Review pattern in A Scrum Book stresses a point that practice often forgets: the product is put in people's hands and decisions are drawn from it, rather than a presentation being run through. A second pattern, Product Wake, deals with the last possible review, the one where you decide to end a product.

Forty minutes of slides

A team is developing an appointment booking tool for a group of health centers. On the last day of the Sprint, it brings together the director, two doctors and the head of the reception staff. A developer projects a slide show listing fourteen "delivered features", with screenshots. The director asks whether the go-live date still holds, is told that it does, thanks everyone, and the room empties. Nobody has touched the tool.

Three weeks later, a medical secretary discovers that she cannot book two consecutive slots for a long consultation, something she does ten times a day in her paper planner. She had always known about this need. Nobody had asked her, and the end-of-Sprint meeting had given her no opportunity to say so.

That meeting bore the name of Sprint Review without doing its job.

Sprint Review: closing the Sprint on the real state of the product

The Sprint Review pattern sits at the moment when the production phase of the Sprint comes to an end. Its problem is one of closure: you need to establish where the product really stands, and having checked off a list of expected results guarantees neither that it has moved forward as much as needed nor that the team will then take the right direction.

The authors describe several forces. During the Sprint, the Developers work among themselves, sheltered from interruptions. This protection has a downside, since a team left too long with its own impressions can drift away from the product's intent. A good Product Owner has a concrete picture of what they are asking for, but nobody foresees everything in a complex product: something concrete almost always raises questions that had not come up in discussion. Communication between the Product Owner and the Developers loses information, and each side keeps assumptions it did not think to state. Finally, any list of requirements is incomplete, because some needs remain unknown to everyone until the product has been tried.

Hence the pattern's central argument: to know what is really going on, you have to examine a working product. Checking off lines in the Sprint Backlog is not enough.

The solution is to end the production phase with an event that assesses the state of the product and informs the team about users' needs, risks, opportunities, problems and likely completion dates. The Developers, the Product Owner and the stakeholders the Product Owner has invited take part. They discuss what is ready to be put into service and what is not, what the Sprint has taught them about the product, and plans for what comes next. The group seeks agreement, but the Product Owner has the last word. The authors advise the Product Owner to invite important users and to ask for their opinion.

What happens during the review

The book lists typical activities:

users handle the product themselves;
the group discusses whether the Sprint Goal was met;
the Product Owner states which items are Done and which are not, then the Developers show what is Done;
the group examines the direction of the product and the order of the Product Backlog, focusing on what it is learning;
it reviews indicators of the product's health, such as velocity, the estimated level of technical debt, the state of defects and progress on the roadmap;
and it checks the follow-up on the actions decided at the previous review.

Several practical rules aim to keep the review from turning into a show. The Developers should spend no more than about half an hour preparing it. The product is shown in an environment close to the user's, without temporary scaffolding meant to make it look better than it is. The authors sum this up with a quip: "No PowerPoint® (unless your product is PowerPoint)." They set the length at three hours at most.

They also ask the Product Owner to accept a vulnerable position, by listening to whether the team approves of their choices on the product's direction, technical debt and quality. The review covers the product only. How the team has worked belongs to the Sprint Retrospective.

The same review, done differently. In the next Sprint, the Product Owner of the booking tool invites two medical secretaries. The team installs the tool on a computer like those at reception and prepares no slides. The Product Owner first announces that three items out of five are Done and that the other two go back to the Product Backlog. Then she hands the keyboard to one of the secretaries: "Mrs. Arnaud is calling for a prescription renewal and a vaccination. Book her appointment as you usually would."

The secretary looks for a way to book forty minutes and finds only twenty-minute slots. She explains that she blocks two consecutive slots for this kind of request.

Within an hour, the group has decided three things. An item "book several consecutive slots" goes to the top of the Product Backlog. The "monthly statistics" item, planned for the next Sprint, moves down the list. And the team notes, for its retrospective, that no secretary had been consulted while the items were being refined.

What the review can teach, and what it cannot

The pattern is clear-sighted about the limits of the event. Many practitioners see the Sprint Review as Scrum's main feedback mechanism. The authors qualify this. In three hours, a Product Owner and a few guests cannot always judge whether a complex Increment meets the need. A sounder judgment comes from using the product in real conditions, over a longer period.

What participants do notice well, on the other hand, are the gaps between what each person thought had been agreed at Sprint Planning and what was delivered. According to the authors, these gaps come less often from the customer changing their mind than from a flaw in the way of working: a question not asked, an assumption not checked. One of the review's main functions is therefore to spot these flaws and pass them on to the retrospective. The last decision in the previous example is a case in point.

The book also sees the review as an occasion for pride and sometimes for celebration. It mentions a Finnish company that occasionally held its review in a sauna, over a good meal.

The discharge booklet. In a day surgery unit, a nurse manager and four care staff are redesigning, in two-week Sprints, the booklet given to patients after their operation. For the review, the nurse manager, who acts as Product Owner, has invited two former patients and a community nurse. The team does not comment on the booklet page by page. It hands it out and sets a situation: "It is 10 p.m. and there is blood on your dressing. What do you do?"

The two patients leaf through the booklet and take more than a minute to find the "When to call" section, placed on page 6 after the administrative information. The community nurse points out that the booklet does not say which dressing was applied, and that she has to call the unit for every patient.

The nurse manager reorders her Product Backlog in front of everyone. Moving the "When to call" section to the back cover goes to the top, followed by a liaison sheet for the nurse visiting at home. The map of the parking lot, which the team had meant to tackle next, will wait. The review lasted forty-five minutes.

Product Wake: knowing when to end a product

Every Sprint Review raises, at least implicitly, the question of whether the product still deserves the effort put into it. The Product Wake pattern deals with the day the answer is no. A wake, of course, is the gathering held around the dead. The context is that of a product that has fulfilled its mission, whose usefulness has passed, or which clearly will not reach its goal.

The problem, according to the authors, is that ending a product is often what organizations do worst. Those who created it have become attached to it as to a child. You can always spend enough energy to keep a product alive, even when what it brings no longer justifies the expense. An ending is painful because it touches several people's livelihoods. Yet persisting usually leads to a series of staff cuts spread out over time.

The solution is to give the product a dignified funeral: bring the work to a clean close, keep the process transparent so that stakeholders are not caught by surprise, and hold a retrospective that places the product in its history and archives what it taught the team.

The book points out that Scrum does not say when to end a product. It simply recalls that the Product Owner is accountable for value and therefore has to decide, with the broadest possible agreement. Return on investment is one criterion; feeling and experience are others. It is better to stop before the product's value turns lastingly negative. Not every ending is a failure, either: the software written for a city's festival is retired once the festival is over. The team does not necessarily break up, and the Product Owner and the Scrum Master help everyone find their next place.

A public library replacing its old email reservation service offers a modest example. The team sets a closing date and announces it to library users two months ahead. It devotes its last session to noting what this service taught it about readers' habits, then archives the useful data and deletes the rest.

What the 2020 Scrum Guide says

The Guide gives the Sprint Review the purpose of inspecting the outcome of the Sprint and determining future adaptations. It makes it a working session and asks the Scrum Team to avoid limiting it to a presentation, which matches the pattern.
The maximum length is four hours for a one-month Sprint, and less for a shorter Sprint. The book says three hours: this is a discrepancy with the Guide, in its 2017 edition as in the 2020 one.
The 2020 Guide has the group discuss progress toward the Product Goal, introduced in that edition. The book speaks of vision and roadmap.
The 2017 edition detailed the content of the review, including the demonstration by the Development Team and the review of the timeline and budget. The 2020 edition removed that list.
In the book, the Product Owner assesses the items and decides whether to accept them. The 2020 Guide contains no such notion of acceptance: an item that does not meet the Definition of Done cannot be presented, and the review is not a required step before releasing.
The Guide says nothing about ending a product. It states only that the Scrum Team must fulfill or abandon one Product Goal before taking on the next.

Limits and pitfalls

The most common drift is the one in the opening scene: a carefully prepared demonstration in front of an audience that listens. It reassures everyone and teaches nobody anything, because a polite guest does not contradict a slide show. Having people handle the product reveals more than asking for an opinion.

The opposite drift turns the review into a court. Managers use it to point out what was not finished and to call people to account. Ron Jeffries described this situation in his 2016 article "Dark Scrum", presented in the corpus's critical article. A team that expects to be judged prepares its defense and shows as little as possible.

A review can also have no effect at all. If the stakeholders do not come, the team presents its work to itself. If the Product Backlog comes out of every review unchanged, either the Product Owner forecasts remarkably well or the feedback is not being taken into account.

On the effectiveness of the event, caution is needed. In a survey of about 2,000 Scrum teams published in 2023, Christiaan Verwijs and Daniel Russo find that the quality of Sprint Reviews is among the factors associated with the teams' reported effectiveness. These are questionnaire answers, collected at a single point in time, which do not allow a conclusion about cause and effect. The pattern's recommendations, for their part, come from its authors' experience.