Sprint Review: From Demonstrating to Deciding

A Sprint Review exists to inspect the outcome of the Sprint and to agree with the key stakeholders what is adapted next. It is a working session on the Product Backlog and not a presentation for an audience. Run as a demonstration, the review earns applause but no decisions. This article sets out the purpose of the review, its agenda and a maturity model, following the Scrum Guide 2020.

In many organisations that use Scrum, the Sprint Review is the most visible event and the one with the least effect. The team shows features, managers nod, and the next Sprint starts with the same Product Backlog as the last. The delivery perspective asks a different question: which decision has been made after the review that was open before it?

What is the purpose of a Sprint Review?

According to the Scrum Guide 2020, the purpose of a Sprint Review is to inspect the outcome of the Sprint and determine future adaptations. The Scrum Team presents the results of its work to key stakeholders and discusses progress towards the Product Goal. The Guide describes the review explicitly as a working session that the team should avoid limiting to a presentation. It is the second-to-last event of the Sprint, and the retrospective follows it.

Three tasks follow from the purpose. First, the review checks what is actually done. An Increment counts as done when it meets the Definition of Done, as the article on the Definition of Done explains. Second, the group assesses what the results mean for the Product Backlog: which items change, which drop out, which move up? Third, the Product Owner discusses how the market, the budget and possible delivery dates have shifted since the last review. The Scrum Guide adds that the Product Backlog may be adjusted to meet new opportunities.

The review is therefore where delivery and steering meet. A team that delivers sprint by sprint without anyone with decision authority looking on produces work in progress without steering. A management that only reads status reports steers on estimates instead of observation.

Who attends a Sprint Review?

The whole Scrum Team and the key stakeholders attend a Sprint Review. The Scrum Team consists of the Product Owner, the developers and the Scrum Master. Stakeholders are people affected by the outcome or involved in decisions on budget and priority: heads of department, users with a decision role, representatives of neighbouring teams. A list that grows too long dilutes the conversation. A list without the decision makers turns the review into an exercise without consequences.

A simple rule guides the selection: invite those who can change something in the Product Backlog during the coming two weeks or who are directly affected by a change. Everyone else receives the outcome as a short summary. It makes sense for the Product Owner to own the invitation, because the Product Owner steers the value of the product and needs feedback from the people who judge it. How this role is staffed in medium-sized companies is described in the article on the Product Owner in the Mittelstand.

How long does a Sprint Review take, and how does it run?

According to the Scrum Guide, a Sprint Review lasts at most four hours for a one-month Sprint and is shorter for shorter Sprints. In practice, one to two hours is usual for two-week Sprints. The Guide does not prescribe the agenda, but a proven frame has five parts.

1. Starting point: The Product Owner recalls the Sprint Goal and the Product Goal so that everyone applies the same yardstick.
2. Outcome: The team shows what has been completed, on the running product and not on slides. Items that are not done are named and not demonstrated.
3. Feedback: Stakeholders try things out and ask questions, then say what convinces them about the result and what is missing. The facilitator records every piece of feedback against the Product Backlog.
4. Outlook: The Product Owner shows the Product Backlog with the new insight, the likely order and the position against the Product Goal.
5. Decision: The group decides what changes, and the Product Owner confirms the changes aloud. Open points get an owner and a date.

The last part separates a review with effect from a demonstration. If it is skipped, the knowledge of the group stays in the room, and the Product Owner has to gather the changes laboriously afterwards.

How mature is your Sprint Review?

A Sprint Review can be placed on four maturity levels that build on one another. The placement shows which step makes sense next and keeps teams from jumping to formats for which they lack the prerequisites.

Many teams start at level two. The move to three works through trying out instead of watching: stakeholders operate the product themselves while the team observes. The move to four requires that the decision makers are in the room and have the mandate to change the order and adjust the scope. Where the mandate is missing, the cause lies in the organisation, and no review format fixes it.

Why do Sprint Reviews fail?

Three causes explain most reviews without effect. The first is a missing decision maker: the participants are representatives without a mandate who take wishes away that vanish again by the next round. The second is a result that cannot be shown. Work on interfaces or data models is hard to demonstrate, and teams then retreat to slides. Cutting the work into results that a user can assess solves the problem already in planning. The third cause is fear of unfinished results. If a team is judged in every review instead of advised, it shows only polished work, and the feedback arrives too late.

A note on the role of management: a review understood as an acceptance gate loses its function. Acceptance of quality is covered by the Definition of Done within the Sprint. The review asks whether the right thing is being built. How Sprint results translate into dependable commitments on dates is shown in the article on release planning.

How do the Sprint Review and the retrospective differ?

The Sprint Review inspects the product, and the retrospective inspects the collaboration. In the review the team and the stakeholders sit together, and the conversation concerns the Increment and the Product Backlog. In the retrospective the Scrum Team stays among itself and plans improvements to the quality and effectiveness of its work. The two events answer different questions and do not replace each other.

Sprint Review with Niehues Consulting

Niehues Consulting is a consultancy for AI management and organisation design from a delivery perspective, based in Düsseldorf. Founder Marin Niehues builds organisations that deliver and works as a delivery manager and project manager as well as product owner, in projects ranging from VC-funded scale-ups to DAX 40 groups and in more than 20 countries on six continents. In the service area of delivery management and organisation design, the work concerns roles, decision paths and interfaces, which is where reviews tend to stall in practice.

The approach follows the Niehues Delivery Model. For the Sprint Review two of its checking questions matter: Who decides, who delivers, who uses the result? Which roles does operation need, and which decision paths and interfaces? Where these answers are missing, every review remains a demonstration, even with good facilitation. The entry point is a free initial consultation of 30 minutes, which you can book through the contact form.