The Review Is Not a Demo

Published August 10, 2026

In brief

Most sprint reviews are only demos. What the review is actually for, and how to get the real one back.

Most teams that run a sprint review are running a demo. Nothing about the plan changes, because nobody actually discussed it.

Sprint review might be the most important recurring event in agile software development, and it's the one most teams get the least value out of. Both are true, and the collapse into a demo is the reason: when the review becomes a demo, everything else it's supposed to do goes with it.

Combine review and demo without protecting both halves, and all the review stuff doesn't happen — only the demo happens. Then the review has to happen in planning, with planning, which usually means less planning actually happens. The review's content still has to go somewhere; it lands in the next day's planning meeting, which isn't built for that job. Planning ends up spending its time on the review that should have already happened, instead of deciding what to build next.

This isn't a new complaint from me. I wrote the same thing in 2021, under a title I chose as deliberate clickbait to get people to read it: “Sprint review is the most important Scrum event - and the one you're probably doing most wrong.” That post opened on the same claim, in capital letters: “THE SPRINT REVIEW IS NOT A DEMO. A demo might be a small part of your sprint review, but demoing is not the point.” Five years later, the same problem holds.

The standard itself has moved toward it. The 2017 Scrum Guide called the Sprint Review “an informal meeting, not a status meeting.” The 2020 revision tightened the language further: “The Sprint Review is a working session and the Scrum Team should avoid limiting it to a presentation.” Its stated purpose: “to inspect the outcome of the Sprint and determine future adaptations.”

A real review runs through the work board, item by item: what got completed, what got started but not finished and why, what never got started and why, and what organizational blockers got in the way. Then it re-checks value on anything unfinished, still worth doing or not, and looks at the bigger picture: how what did and didn't happen changes the next cycle's plan, and what's shifted in the market or the organization that the plan needs to account for.

A team that's only running a demo doesn't have to build this from scratch. The conversion starts wherever the team already is, added onto whatever's already on the calendar rather than scheduled as something new. The full sequence, the roles, and a runnable script for making the switch are in The Review Playbook.

The demo itself gets a distinctive rule. My default: a lead stakeholder or key owner, someone closer to the end user than the team is, drives the demo hands-on, instead of watching the team walk through it. If it works in their hands, that's a good sign it will work for the user. The pattern has real precedent: LeSS's own framework guidance prefers “an active session in which real users and the Product Owner do hands-on interaction with the software, rather than a passive-session demo from the Team,” and Christiaan Verwijs has written about handing the stakeholder the keyboard for the same reason. What's less common is treating closeness to the end user as the deciding rule for who runs the demo, rather than one engagement tactic among several. That part is my own synthesis of a pattern others have gestured at.

The scheduled demo also isn't where feedback starts. It's never a work item's first demo: work that's ready gets shown as soon as it's ready, in standup or on a quick call. I want feedback as early as possible, and I don't want to wait for it.

Look at the last review your team ran. Ask whether the plan changed because of it, or whether the team watched a demo and moved straight into planning the next day regardless. If it's the second one, the fix is already on the calendar. This week, extend that meeting: add the work-board walkthrough and the market-and-direction beat a demo-only meeting skips, rather than scheduling something new nobody has time for.

Back to Field Notes