Most sprint reviews are demo theatre. Engineers tile up screens of work that’s already shipped, stakeholders nod politely, the PM thanks everyone, and nobody walks away with anything they didn’t already know.
This is a waste of an hour, every two weeks, for a whole team. Across a year that’s roughly £5,000-£10,000 of pure ceremony cost (at typical engineering loaded salaries). And the worst part isn’t the cost — it’s the missed opportunity. The sprint review is the one meeting where the team and the people who care about the product are in the same room. If it produces nothing but applause, that’s a failure of design, not of the participants.
Here’s the honest read on what a sprint review is for, where it goes wrong, the three signals you’ve got demo theatre, and what to do instead.
What a sprint review is actually for
Strip away the agile training-deck definitions. The sprint review exists to answer one question:
“Given what we shipped this sprint and what we learned, should we change what we plan to ship next?”
That’s it. Everything else — the demo, the stakeholder Q&A, the retrospective tone of “what we accomplished” — is in service of that one question, or it doesn’t belong.
Three things flow out of a working sprint review:
- Validation or invalidation — what we shipped either solves the problem we thought, or it doesn’t. The demo is a tool to surface that, not the point.
- Reordering — based on what we just learned, what’s now more or less important in the next sprint?
- Stakeholder signal — what do the people who care about this product think happened, and what do they want next?
If your sprint review doesn’t change at least one of those three things, it isn’t doing work.
How sprint review becomes demo theatre
The drift is consistent and predictable.
Drift 1: It becomes about the team’s productivity, not the product.
The first slide is “what we accomplished this sprint.” Engineers walk through what they shipped. The vibe is “look how busy we were.”
This is the dominant failure mode. It’s emotionally understandable — engineers want their work seen — but it’s the wrong frame. Stakeholders care about the product getting better, not how hard the team worked. The two are correlated but they’re not the same thing, and the meeting starts confusing the two.
Drift 2: The audience becomes passive.
Stakeholders learn that sprint review is a place to listen, not to engage. They show up, watch the demo, ask one polite question, leave. The team learns the same thing in reverse — present, don’t ask. Both sides settle into a script.
After 6-8 sprints of this, you have a meeting nobody wants to skip but nobody gets value from either. It’s a habit, not a tool.
Drift 3: The work shown is what’s polished, not what matters.
Engineers prep their best-looking ticket for demo. Bug fixes don’t get shown. Infrastructure work doesn’t get shown. Half-finished prototypes don’t get shown. The review becomes a curated highlight reel.
The result: the meeting is unrepresentative of what the team actually did, and stakeholders walk away with a wildly inaccurate picture of where the product is.
Three signals you’ve got demo theatre
If two of these are true, the meeting is decoration.
1. The next sprint plan is identical to what you’d planned anyway
If sprint review never changes the next sprint, it’s not doing work. The whole point is feedback into planning. If planning happens the same way regardless of what review surfaced, review is purely decorative.
2. The same demo content would land equally well as a Loom video
If a stakeholder could watch a 5-minute recorded walkthrough and get the same value as attending the live meeting, the synchronous time isn’t paying off. Async-able content shouldn’t be sync.
3. Nobody asks hard questions
A working sprint review has at least one moment of uncomfortable conversation per session — a stakeholder pushing back on direction, a PM disagreeing with engineering, an unflattering metric being surfaced. If your reviews are entirely polite, the meeting has stopped being useful.
The fix: shift the structure
The good news: sprint review can be fixed without scrapping it. Three structural changes make a difference.
Fix 1: Open with the goal, not the work
Before any demo, restate the sprint goal you set in planning. Then ask: did we hit it? Yes / no / partial. One sentence each.
This forces honesty up front. If the answer is “no, but here’s what we shipped instead,” the meeting becomes a real conversation about why, instead of a parade of unrelated tickets.
Fix 2: Demo with intent, not chronology
Don’t walk the sprint board ticket-by-ticket. Pick the 2-3 things that changed your understanding of the product and demo those.
A bug fix that revealed a user pattern you didn’t know about → demo. A feature that landed exactly as designed → mention, don’t demo. A spike that produced an unexpected technical insight → demo.
This is hard to do for the first few sprints because the team isn’t used to filtering. After 3-4 sprints it becomes natural and the meeting tightens to 30 minutes from 60.
Fix 3: Reserve the last 20 minutes for “now what?”
Half of a working sprint review should be a live conversation about the next sprint. Not “here’s what we plan” — that’s planning’s job — but “given what we just saw, what’s now wrong with the plan?”
Put the next-sprint backlog up on screen. Ask stakeholders: “Anything in here that should drop, given what you just saw?” Ask PMs: “Anything that should be added or moved up?” Ask engineers: “Anything that’s now blocked or revealed as harder than we thought?”
This single shift — from “show then end” to “show then plan” — is the single biggest unlock for sprint review value. The meeting starts producing real reordering, real cuts, real escalations.
The agenda that works
For a 60-minute review with a 6-person team:
| Time | Section | Owner |
|---|---|---|
| 0:00 | Sprint goal: hit / partial / miss + one-line reason | PM or lead |
| 0:05 | 2-3 demos that changed our understanding | Engineers |
| 0:30 | What’s the most important thing we learned? | Whole team |
| 0:40 | Now-what: live look at next sprint backlog, reorder/cut/add | Whole team |
| 0:55 | Decisions captured, owners assigned | PM |
| 1:00 | End |
Cut the demo section to 15 minutes if your team is small or the sprint was tight. The “now what” section is the one to protect — that’s where the value comes out.
What about distributed / async teams?
Async sprint review is genuinely possible and works for tight remote teams.
Format:
- Day 1 of sprint review: each engineer posts a 1-2 minute Loom demo of one thing they shipped that surprised them, plus a sentence on what it implies for the next sprint. Posted to a shared thread.
- Day 1 evening: stakeholders watch and react in the thread (questions, “this should be higher priority,” etc.)
- Day 2: 30-minute live “now what” conversation. The demos are already in everyone’s head — just talk about reordering.
This works because the synchronous time gets spent on the actually-synchronous part: the conversation, not the broadcast.
It doesn’t work if the team is mostly junior or the stakeholders aren’t engaged enough to watch async content. In those cases stay with sync.
The rare case: when to actually skip sprint review
A sprint review is high-value when:
- You ship to live users every sprint and learn something from their reaction
- Stakeholders aren’t in the day-to-day and need a structured update
- Engineers and PMs aren’t in constant contact
It’s lower-value when:
- The team and stakeholders talk every day anyway
- The sprint goal is clearly defined and tracked elsewhere
- The product is internal and the “stakeholder” is a single PM in the team
For tight, fully-aligned teams shipping internal tooling, sprint review can become a 15-minute async post in a Slack channel. That’s fine. Don’t run a full meeting just because the framework says to.
The honest summary
Sprint review is the only ceremony where the team and the people who care about the product are in one place. Don’t waste that.
Stop opening with “what we accomplished.” Stop demoing chronologically. Stop ending without a “now what” conversation. Stop measuring success by whether the demo was smooth — measure it by whether the next sprint plan changed because of the meeting.
A good sprint review is uncomfortable at least once per session. If yours is always polite, it’s already drifted into theatre. The fix is a 5-minute structural change, not a culture overhaul.
Sprint review isn’t a deliverable. It’s a feedback loop. Run it like one.
Tools to help:
- Sprint Health Check — quick assessment of sprint health across goal-hit-rate, scope creep, blockers, retro action follow-through.
- Sprint Maturity Self-Assessment — see where your team sits on the maturity curve.
- Definition of Done Generator — pin a DoD to every issue so “shipped” actually means done.
SprintFlint surfaces ticket-by-ticket sprint progress, sprint goal status, and reordered backlog in one view — sprint review prep takes 0 minutes. Free for the first 300 tickets — no card.