The sprint review: a working session, not a demo performance

The sprint review has a branding problem. Most teams call it "the demo", and the name quietly rewrites the meeting: a performance, an audience, applause if it goes well, embarrassment if it does not. Then, over a few months, the audience stops coming, the demos get pre-recorded, and someone suggests moving it to monthly.

The Scrum Guide describes something different and much more useful: a working session where the team and its stakeholders inspect the increment together and decide what to do next. The demo is in there, but it is the means, not the point. The point is the sentence that comes after the demo: "given what you just saw, is the plan still right?"

What the review is for

The review closes the sprint's outer feedback loop. The daily scrum inspects progress toward the Sprint Goal; the review inspects the product itself, against the market, the customers, and the Product Goal. Its concrete outputs are:

• A shared, honest understanding of what is actually done.
• Stakeholder feedback captured while it is fresh.
• A revised product backlog. This is the tell of a healthy review: the backlog after the meeting looks different from the backlog before it. If six months of reviews have never reordered anything, the meeting is decoration.

Timebox: at most four hours for a one-month sprint, so around one to two hours for the two-week sprints most teams run. It is the second-to-last event of the sprint, before the retrospective.

Who should be in the room

The whole Scrum team, plus real stakeholders: the people whose opinion of the product has consequences. Depending on your context that means customers, customer-facing colleagues from sales and support, executives, partner teams that consume your APIs, or actual end users.

Getting the right outsiders in the room is the Product Owner's hardest and most valuable job here. A review attended only by the team is a rehearsal with extra steps; the entire value of the ceremony comes from contact with people who will tell you something you did not already believe.

A story that illustrates the stakes. A B2B team we know spent three sprints building a configurable reporting engine, reviewed each increment internally, and shipped. The first time an actual customer success manager saw it, she asked one question: "Which of these can I export to Excel? That is all my accounts ever ask for." Excel export was a two-day ticket that had sat in the backlog un-ordered for months. Three sprints of internal reviews had inspected the work; one review with the right person in the room inspected the value. That question should have been asked twelve weeks earlier, and the only reason it was not is that she had never been invited.

Done means done

One rule keeps reviews honest: only work that meets the Definition of Done gets shown. No feature branches that "just need review", no localhost-only demos of things that will be integrated next week, no slideware standing in for software.

This rule exists because the review is where the organisation calibrates what "the team finished X" means. Show almost-done work as done a few times, and stakeholders learn to mentally discount everything they see, which corrodes the transparency the whole framework runs on. Undone work is not shameful; it goes back to the backlog and gets said out loud. Pretending is the failure mode, not missing.

A working agenda

For a two-week sprint, sixty to ninety minutes:

1. Frame it (5 minutes, Product Owner). State the Sprint Goal and whether the team believes it was met. Name what was planned but not finished, plainly and without theatre. This ten-sentence opening sets the honesty level for the whole meeting.

2. Show the increment (25 to 40 minutes, Developers). Demo the finished work as user-visible journeys, not as a ticket-by-ticket readout. "Here is a customer paying by invoice, end to end" beats walking the column of done tickets in order. Let the people who built each piece drive; the review is one of the few moments the wider organisation sees engineers as the owners of the product rather than resources behind it. Where possible, demo in a real environment with real-ish data, and even better, let stakeholders drive the product themselves; watching a stakeholder fumble with your navigation is feedback no survey will ever give you.

3. Discuss (15 to 30 minutes, everyone). This is the actual meeting. Useful prompts: What surprised you? What would you change before this reaches customers? Does this change what you need next? Capture every piece of feedback as a concrete artifact, not a vibe. The lowest-friction pattern is to create backlog tickets live, in the meeting, as the feedback lands. In WannaTrack this takes seconds per item: type the one-line gist, let the AI assistant expand it into a proper description with acceptance criteria as a starting draft, and drop it into the backlog to be ordered later. Feedback that becomes a ticket in the meeting survives; feedback that becomes a note in someone's pad usually does not.

4. Look at the numbers (5 to 10 minutes, Product Owner). Zoom out from the sprint to the trajectory: progress toward the Product Goal, and how the release is tracking. A burnup chart is the natural instrument here because it shows scope changing as well as work completing, so "we added two weeks of scope in the last month" is visible instead of deniable. If timelines and dependencies come up, resolve them against a live plan rather than promising to "check the roadmap later"; this is what WannaTrack's timeline view is for, epics and sprints on one schedule, so the "when does this land?" conversation happens with the evidence on screen.

5. Decide (5 minutes, everyone). End with explicit direction: what the feedback means for the backlog order, and roughly what the next sprint should aim at. This decision feeds directly into the next sprint planning, which is why the review comes first.

Publish a short summary afterwards: what was shown, what was decided, what entered the backlog. A doc that lives next to the project, with the decisions linked to the tickets they created, beats an email nobody can find in three weeks.

Anti-patterns and their fixes

The performance. Weeks of preparation, a polished script, a rehearsed happy path. If preparing for the review takes more than an hour, the team is optimising for applause rather than feedback. Fix: demo from the real product, accept that live demos sometimes stumble, and treat a stumble in front of stakeholders as a bug report with excellent timing.

The acceptance gate. The review is treated as the moment the Product Owner accepts or rejects the sprint's work, sometimes with sign-off ceremony. This is too late by design; the Product Owner should be seeing work as it finishes, during the sprint, on the board. If the review regularly contains surprises for the Product Owner, the problem is collaboration during the sprint, not the meeting.

The empty room. Stakeholders stopped attending. This is a symptom with two common causes: the meeting stopped affecting decisions (why attend a readout?) or repeated dishonest demos taught people to discount it. Both are fixable, but by making the meeting consequential again, never by making attendance mandatory.

The ticket recital. Reading the done column aloud, ticket by ticket, with points. Stakeholders do not care about tickets; they care about what the product can do now that it could not do two weeks ago. Anyone who wants the ticket-level detail can read the board and reports themselves, which is also the better answer for the executive who only wants the status: send a link to the live dashboard, not a meeting invite.

Feedback that evaporates. Great discussion, nods, no artifacts, and the same conversation three sprints later. Fix is mechanical, not cultural: no piece of feedback leaves the room without becoming a backlog item, a decision in the notes, or an explicit "no, and here is why" from the Product Owner.

The review's real product

Judge a sprint review by one question: did we learn something that changed the plan? Not every review will reorder the world, but across a quarter, the reviews should have visibly steered the product. That steering is the entire economic argument for working in sprints; each review is a chance to correct course while corrections are still cheap.

After the review inspects the product, one more ceremony closes the loop by inspecting the team itself. That is the sprint retrospective, covered next.