The Sprint Review occupies a specific and important position in the Scrum framework. It is the event where the empirical heart of Scrum becomes concrete: real work is inspected by real stakeholders, real feedback is gathered, and the Product Backlog is updated based on what is learned. Done well, it is one of the most valuable events in the Sprint. Done badly — as a formality, a presentation, or a performance review of the development team — it produces compliance without insight.

What it is for

The purpose of the Sprint Review is to inspect the Increment and adapt the Product Backlog accordingly. This sounds simple but has significant implications for how the event should run.

"Inspect" means genuinely examining what has been built: whether it works as intended, whether it delivers the value the team expected, and whether it changes what the team and stakeholders understand about what should come next. This is a working session, not a show-and-tell. Stakeholders should be engaging with the actual product, asking real questions, and providing feedback that can be acted on.

"Adapt" means that the Product Backlog should be visibly different at the end of a Sprint Review than it was at the beginning. New items may be added based on what the demonstration revealed. Existing items may be reprioritised based on feedback. Items that no longer make sense in light of what was built may be removed. A Sprint Review where the Backlog is unchanged is a Sprint Review where no genuine learning happened.

How to run it

Preparation. The Scrum Team reviews the Sprint Backlog before the event, ensuring all completed work genuinely meets the Definition of Done. Anything that does not meet the DoD should not be presented as complete. Stakeholders should be invited with enough notice to attend meaningfully, and they should understand the purpose of the event — not as an approval ceremony but as a collaborative working session.

Presenting the Increment. The development team demonstrates what was built during the Sprint. The emphasis should be on showing working functionality rather than slides or reports about functionality. Real users and stakeholders engaging with real software produces more useful feedback than any presentation. If the Increment cannot be demonstrated, that is itself significant information about the nature of the work.

Gathering feedback. After the demonstration, the conversation shifts to feedback and questions. What did stakeholders observe? Does it match what they expected? What does it reveal about what is needed next? This is an active, collaborative discussion — the Scrum Team should be listening more than presenting at this stage.

Deciding on next steps. The final part of the Sprint Review is forward-looking: what does what was learned in this session mean for the Product Backlog? What should move up, what should move down, what should be added? The Product Owner typically facilitates this conversation, and the output should be a set of concrete changes to the Backlog rather than general impressions to be processed later.

Who attends

The Scrum Team — Product Owner, Scrum Master, and Developers — attends the Sprint Review. The Product Owner typically handles invitations to stakeholders, who may include customers, users, executives, or other teams. The Scrum Guide is flexible about who specifically should attend, reflecting the reality that relevant stakeholders vary by context and sprint.

One note: the Sprint Review is not a closed event. Bringing in a broad range of stakeholders — including people who were not involved in writing the requirements — often produces the most useful feedback. The person who uses the product daily but was never consulted about its development frequently has the most direct insight into whether what was built is actually useful.

Common failure modes

The Sprint Review most commonly fails when it becomes a formality: a regular slot in the calendar where the team presents work to a largely passive audience who approve it and move on. When stakeholders are not engaged, feedback is not specific, and the Backlog does not change, the event has become overhead rather than value.

Fixing this usually requires changing the room dynamics more than the agenda: fewer slides, more demonstration, more genuine questions, explicit time for Backlog discussion. The event should feel like a collaboration between the team and the people the product serves, not a quarterly report from one party to another.