Articles

The Sprint Review Is Broken

AI increases delivery speed, making Sprint Reviews more important for feedback, learning, and product direction.

Robbin Schuurman

June 19, 2026

12 minutes

Article 5 of 9 in the series.

Picture a Sprint Review that everyone in the room agrees is a success. The Product Owner walks stakeholders through three features. The demo is smooth. The UX has been polished by an AI design agent the week before, and it shows. Stakeholders nod, ask two friendly questions, and give the team a round of applause. The retrospective afterward includes a pat on the back about stakeholder engagement.

Two weeks later, adoption on all three features is under fifteen percent. The same stakeholders are in the escalation meeting. The Sprint Review measured satisfaction with the presentation, not with the product. That is the pattern I want to name and retire in this article.

In the first four articles of this series, I introduced a Definition of Value, argued accountability concentrates rather than dissolves, reframed refinement as option framing, and raised the bar on the Increment to require adoption. All four of those threads converge on one Scrum event. That event, today, is the weakest link in the AI-powered team's operating rhythm. Why is the Sprint Review so consistently failing the teams that need it most?

This is a visionary piece, not a predictive one. I cannot tell you exactly what the Sprint Review will become over the next five years. I can share how a room full of experienced Professional Scrum Trainers thinks it has to evolve, and why a different agenda, starting with your next one, will change the signal you get from it. The full list of contributors from the Amsterdam Face-to-Face Event sits at the foot of the article. The arguments here are mine. The thinking is ours.

The Scrum Guide Called It Right

The Scrum Guide describes the Sprint Review as a working session. The Scrum Team and stakeholders inspect the outcome of the Sprint and determine future adaptations. The Guide does not use the word demo anywhere.

Make no mistake; the Scrum Guide is not broken on this event. The vocabulary, the purpose, and the expectation of stakeholder collaboration are all in the right place. What has drifted, in practice, is the event itself; a working session has quietly become a presentation in too many product teams. AI is not the root cause of that drift, but it is about to make the symptom much worse.

Why the Demo Pattern Persists, and Why AI Makes It Worse

Three forces keep the demo pattern alive. Demos are easy to produce. Stakeholders are trained by decades of corporate rituals to expect them. And the feedback signals from a demo, turnout, nods, smiles, applause, are easier to read than the signals from real outcome inspection.

AI now makes the first force trivially strong. An agent can polish a demo flow, generate the walk-through script, and render the feature to look its best in under an hour. That is a useful capability. It is also a dangerous one, because polish has always been a proxy for quality, and polish is now cheap. A team can bring a pristine demo to a Sprint Review every two weeks without ever producing a validated outcome.

If the Sprint Review continues to be structured around what AI produces most easily, it is going to become less informative every Sprint.

What a Great Sprint Review Already Looks Like

Before going to the AI-era extension, I want to acknowledge something important. Many product teams I work with have, for years, been running Sprint Reviews that already break the demo pattern; the AI shift in this article does not start from zero, it builds on a way of running the event that already works.

Earlier in 2025, I published two pieces that captured the approach I have been teaching. The first one, How to Run Sprint Reviews That Actually Move the Product Forward, proposes a simple metaphor that reframes what the event is for. The second one, A Practical Agenda and Approach to Hosting Great Product Reviews, turns it into a working two-hour agenda. Together, they are the foundation the rest of this article builds on.

The metaphor is a car. Five parts, each playing a distinct role in the Sprint Review.

The rear-view mirror. Deliberately small. A short, outcome-focused look at what was delivered and what shifted in the Sprint that just ended; just enough context to inform what comes next.
The windshield. Where most of the conversation should go. Where is the product headed, what bets are next, what is changing in the world that affects the direction?
The side windows. Trends, customer signals, market shifts, competitor moves, observations from sales, support, legal. Stakeholders bring these in; the team listens, and adjusts.
The steering wheel. The Sprint Review must produce decisions, or at least set them up. If nothing is ever being steered after the event, it is a status update with extra steps.
The passenger seats. Occupied by stakeholders. They are not an audience; they are co-travellers. Ask their perspective. Share uncertainties. Invite real input.

One more practical tip from the second piece is worth lifting up here, because it changes everything about how stakeholders enter the room. Open the Sprint Review with a story, thirty seconds, that anchors the work to a real human consequence. A customer who was helped, a problem that hurt someone, a mission that got harder this Sprint. Stakeholders engage with stakes; they do not engage with status.

This pattern has been quietly working for product teams for years. Stop demoing, start collaborating is the principle behind it. Most Sprint Reviews that move products forward look much more like this drive, and much less like a presentation.

What follows in the rest of this article is the AI-era extension of the same pattern. The car metaphor stays. The agenda stays. What sharpens, when agents enter the room, is the kind of evidence that needs to be on the table, and the speed at which the team is expected to act on it.

The Evidence Review

Call the AI-era replacement an Evidence Review. It is not a new agenda; it is the car-metaphor agenda, sharpened with the kind of evidence and decision-cadence an AI-powered team needs to bring into the room. The four questions, asked in order, every Sprint Review, without exception, are these.

What did we bet? Pulled directly from the Option Frame from the third article in this series. The Product Owner reads the Outcome and the Bet the team committed to at refinement. No retroactive revising.
What did we ship? Brief, factual, non-performative. The Increment that was released, to which cohort, when. No demo walkthrough unless a stakeholder specifically requests one.
What did users do with it? This is the heart of the event. Adoption data, cohort analytics, support ticket deltas; the Adoption Increment evidence from the fourth article in this series. If the answer is "we do not yet know," the event takes that on as a Product Backlog risk, deliberately.
What is the next bet? The Product Owner proposes, the team and stakeholders interrogate, and the event ends with at least one candidate entry into the next refinement's Option Frame.

The four questions map cleanly onto the car. Questions 1 and 2 are the rear-view mirror; brief, outcome-focused, just enough to ground the rest of the conversation. Question 3 looks out the side windows, and through the windshield together; what did real users actually do, and what is that telling us about the world the product is driving through? Question 4 is windshield-and-steering-wheel, jointly; where do we go next, and what decision is the team making, today, to get there?

Four questions, roughly forty-five minutes, and a working session that produces decisions rather than applause.

What Stakeholders See and Do Differently

Stakeholders who walk into an Evidence Review for the first time are often confused. Where are the screenshots? Where is the walkthrough? Where is the applause moment?

The first two or three Evidence Reviews are quieter than the demo reviews they replaced. Good. That quiet is stakeholders adjusting to being asked to do actual work. The agenda gives them a job: pressure-test the evidence, challenge the next bet, bring what they know about the market, the customer, the competitive landscape. A well-run Evidence Review turns stakeholders from an audience into a second team. That was always the intent of the Scrum Guide. Most stakeholders have simply never been asked to play that role.

Where Agents Help, and Where They Do Not

Agents are legitimately useful inside an Evidence Review. They can roll up adoption dashboards, synthesize cohort comparisons, generate the first-draft analysis of why a bet moved or did not move. They can prepare the materials.

Agents do not present, they do not narrate, and they do not stand in front of stakeholders. The Product Owner is accountable for the evidence narrative, because, as the second article in this series argued, accountability concentrates; it does not transfer. An agent that summarizes the data is a useful assistant. An agent that delivers the Sprint Review is an accountability leak, and a credibility problem waiting to happen.

What This Looks Like in Practice

Return to the SaaS onboarding team from earlier in the series. Under the old demo pattern, their Sprint Review would have walked stakeholders through the redesigned onboarding flow with a clean UX showcase. Nods. Applause.

Under an Evidence Review agenda, the Product Owner instead opens with the Option Frame: the Bet was that removing friction would move activation from 42% to 60%. She shares what was shipped, to which cohort, on which day. Then the adoption data goes up: seven-day activation at 47%, not 60%. Support tickets unchanged. Reactivation rate up slightly. She proposes the next bet: the team now hypothesizes that it was uncertainty, not friction, that was blocking activation, and the next Sprint will test an FX transparency panel for a cohort of SMB users. A stakeholder from sales challenges the hypothesis, offers three recent lost-deal transcripts, and suggests an alternative framing. The Product Owner takes that into the next refinement's Option Frame.

The event ends on time, with no applause and two concrete decisions on the table. That is what an hour of stakeholder time should produce when an AI-powered team is running at speed.

Five Things You Can Do in Your Next Sprint Review

Replace the demo agenda with the four-question agenda. Print the four questions. Put them on the wall. Walk them in order, every Sprint Review, for three Sprints straight.
Bring adoption data, not screenshots. If you cannot answer "what did users do with it," the evidence does not exist yet. Say so. Make that gap the next Product Backlog risk.
Read the room, not just the data. Stakeholders, especially experienced ones, communicate as much in what they do not say as in what they ask. A skilled Product Owner hears the hesitation, the polite smile, the pointed silence, and names it out loud. Agents are bad at this. Humans are paid for it.
End every Sprint Review with at least one candidate for the next Option Frame. No candidate, no event. The Review produces decisions, or it produces nothing.
Track one metric: decision-latency in the Sprint Review. Not attendance, not satisfaction. How fast does the event produce a decision the team can act on next Sprint? If the answer is "we will follow up offline," the governance around the event is too slow. The Sprint Review is where decision-latency for product judgment calls must collapse, not expand.

The Turn

The Sprint Review has always had the potential to be the most valuable hour in the Sprint. For thirty years, that potential has been partly wasted on demos. AI is finally going to force the community to use the event the way the Scrum Guide always intended. Not because the Guide needed to change. Because the cost of staying in demo mode, measured in unadopted features and unhappy stakeholders, has become impossible to ignore.

Over to You

At your next Sprint Review, count the decisions. Count the evidence statements. Count the screenshots. If the last number is larger than the first two combined, you have the conversation your team needs.

The next article goes somewhere quieter, and, I think, more important. If the Evidence Review produces learning every Sprint, where does the learning live? As AI agents take on more of the drafting, coding, and summarizing, the natural places where teams used to accumulate tacit knowledge are disappearing. That is a cost worth naming. See you there.

Contributors

This article was created based on the Scrum.org PST Face-to-Face Event #137 in Amsterdam. It would not have been possible without the discussions with: Dave West, Merel van de Wiel-Riedeman, Tommi Kemppi, Sjoerd Nijland, Jesse Houwing, Robbin Schuurman, Martijn Magermans, Guus Verweij, Steven Deneir, Gregor Stuhldreier, Paul Kuijten, Mehdi Hoseini, Simon Kneafsy, Vivien Colas, Jeroen de Jong, Kate Hobler, Olivier Ledru, Roderick Schoon, Stephan Vlieland, Tiffanie Newton, and Karel Smutný. The arguments here are mine. The thinking is ours.

< Read the previous article