The Sprint Review is not a demo

A team spends the last afternoon of the Sprint making sure the demonstration runs without a hitch. Stakeholders arrive, watch twenty minutes of smooth clicking, say it looks great, and leave. Nothing changes. Everyone feels good, and almost nothing has been learned.

That is a demo. The Sprint Review is meant to be something else.

What the Guide says it is for

The purpose of the Sprint Review, in the Scrum Guide, 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 progress toward the Product Goal is discussed.

Two sentences later comes the instruction that gives this post its title. During the event, the Scrum Team and stakeholders review what was accomplished in the Sprint and what has changed in their environment. Based on this, attendees collaborate on what to do next, and the Product Backlog may be adjusted to meet new opportunities. The Sprint Review is a working session, and the Scrum Team should avoid limiting it to a presentation.

So there are three parts, and the demo is only the first.

1. Inspect the outcome. What was achieved, against the Sprint Goal?
2. Look outside. What has changed since the Sprint began: the market, the budget, the users, the competition?
3. Decide what to do next. What should the Product Backlog look like now?

The event is the second to last of the Sprint, with a maximum of four hours for a one-month Sprint and usually less for shorter ones.

Who is in the room

The Scrum Team and key stakeholders. The wording is deliberate. Stakeholders are the people who can say something about the product that the team does not already know: users, sponsors, the people who will support the system, colleagues in other departments. A review attended only by the team is a rehearsal.

The Product Owner has a particular role. Their decisions are visible in the content and ordering of the Product Backlog and in the Increment, which stakeholders inspect at the review. They are also the person who can change the backlog on the spot when feedback arrives.

What gets shown, and what does not

The Increment is what is inspected. The Guide's rule is strict: if a Product Backlog item does not meet the Definition of Done, it cannot be released or even presented at the Sprint Review. It returns to the Product Backlog for future consideration.

This stops the most common distortion. Teams are tempted to show unfinished work "so people can see where we are". Done work is evidence, and unfinished work is a promise. Putting both on the same screen blurs the line, and stakeholders start to believe that "almost done" is a state.

The Guide also says that an Increment may be delivered to stakeholders before the end of the Sprint, and that the Sprint Review should never be considered a gate to releasing value. Reviews are for inspection and adaptation, not permission.

How the SBOK frames it

The SBOK® Guide approaches the same meeting differently. In its Demonstrate and Validate Sprint process, the Scrum Team demonstrates the Sprint deliverables to the Product Owner in a Sprint Review Meeting, and the purpose is to secure the Product Owner's approval of the Sprint's user stories. The Product Owner reviews each story against its acceptance criteria and either accepts or rejects it. A story is only accepted if it meets all of its criteria, and rejected stories are added back to the Prioritized Product Backlog for a later Sprint.

It also recognises the wider purpose. It calls the process a key element of keeping stakeholders engaged, encourages business stakeholders to take part to gain first-hand knowledge and give feedback, and says their feedback is an important input to future Sprints.

Both views are useful if you keep them apart. The acceptance decision is a quality check on individual stories. The review conversation is a planning exercise about the product. The Scrum Guide's version puts the weight on the second, and the SBOK's on the first. A team can do both in one event, provided the acceptance does not eat all the time. See acceptance criteria for how the first part works.

A sensible shape for the event

There is no required agenda. This is the order we would start with, as a suggestion, and you should change it freely.

1. Restate the Sprint Goal and the Product Goal. A minute or two, so everyone is working from the same purpose.
2. Show what is Done. Use the real product, not slides, and let stakeholders use it where they can. Say honestly what is not finished and why.
3. Collect reactions. Ask specific questions: what surprised you, what is missing, what would you stop?
4. Discuss what has changed outside. New priorities, new constraints, new opportunities.
5. Look at the Product Backlog together. The Product Owner reorders, adds and removes in front of the group, so the effect of the feedback is visible.
6. Agree what the next Sprint might aim for. Not a commitment, but a direction that feeds Sprint Planning.

Common mistakes

• The rehearsed demo. If the team spends a day preparing a polished presentation, the review has become a performance. Showing the real product, rough edges included, produces better feedback.
• Nobody senior or knowledgeable attends. Without the right stakeholders the conversation about what to do next has nobody to have it with.
• Showing work that is not Done. It undermines the Definition of Done and gives false confidence.
• Feedback with nowhere to go. If suggestions are noted and then ignored, stakeholders stop offering them. The backlog should change visibly.
• Treating it as sign-off. The Guide says the review should never be a gate to releasing value, and releasing is a separate decision.
• Skipping it when the Sprint went badly. A poor Sprint is when inspection matters most.

The Agile Manifesto asks that business people and developers work together daily throughout the project. The Sprint Review is the formal moment when that conversation is sure to happen.

How to practise it

The review is where the Definition of Done meets the Product Owner. In the simulator, the developers demonstrate the increment, the Product Owner accepts or rejects each story, and you decide what happens to the work that was rejected.