4.4 The Sprint Review
Key Takeaways
- The Sprint Review is timeboxed to a maximum of 4 hours for a one-month Sprint and is the second-to-last event of the Sprint, immediately before the Retrospective.
- Its purpose is to inspect the outcome of the Sprint and determine future adaptations; the primary output is an adapted Product Backlog.
- It is a working session, not a presentation — the Scrum Guide explicitly says the Scrum Team should avoid limiting it to a demonstration.
- Only work meeting the Definition of Done may be presented as part of the Increment; undone items return to the Product Backlog for future consideration.
- The Sprint Review is never a release gate — an Increment may be delivered to stakeholders before the Sprint Review ever happens.
Quick Answer: The Sprint Review inspects the outcome of the Sprint and determines future adaptations. Maximum 4 hours for a one-month Sprint. Attended by the Scrum Team and key stakeholders. Its output is an adapted Product Backlog. It is a working session — the Scrum Guide says the Scrum Team "should avoid limiting it to a presentation."
Of the five Scrum events, the Sprint Review is the one where the boundary between the Scrum Team and the wider business is deliberately opened. Everything else in Scrum optimizes the team's ability to build; the Sprint Review optimizes the organization's ability to steer.
Purpose, Timebox, and Position
| Attribute | Value |
|---|---|
| Purpose | Inspect the outcome of the Sprint and determine future adaptations |
| Maximum timebox | 4 hours for a one-month Sprint; usually shorter for shorter Sprints |
| Position in the Sprint | Second-to-last event, immediately before the Sprint Retrospective |
| Attendees | The whole Scrum Team plus key stakeholders invited by the Product Owner |
| Primary output | An adapted Product Backlog |
| Format | Working session — collaborative, not a status presentation |
For a two-week Sprint, teams commonly run a two-hour Review. The Scrum Guide states only the one-month maximum and that shorter Sprints usually have shorter events; the proportional figures are convention, not rule.
What Actually Happens
The Scrum Guide describes the Sprint Review compactly: the Scrum Team presents the results of their work to key stakeholders and progress toward the Product Goal is discussed. During the event, the Scrum Team and stakeholders review what was accomplished in the Sprint and what has changed in their environment. Based on that information, attendees collaborate on what to do next, and the Product Backlog may be adjusted to meet new opportunities.
A workable running order:
- The Product Owner frames progress toward the Product Goal and states which Product Backlog items are Done and which are not.
- The Developers show the Increment, hands-on, and answer questions directly. Only Done work is shown.
- The group discusses what has changed in the environment — market movement, competitor releases, regulatory shifts, budget changes, new customer intelligence.
- Attendees collaborate on what to do next. This is the substance of the event, not an afterthought.
- The Product Backlog is adapted in light of the discussion, feeding directly into the next Sprint Planning.
A Correction Worth Internalizing
A very common study-material error places "the team discusses what went well during the Sprint, what problems it encountered, and how those problems were solved" inside the Sprint Review. In the 2020 Scrum Guide that sentence belongs to the Sprint Retrospective. The Sprint Review discusses the product and the environment; the Retrospective discusses the process and the team. If an exam option puts process reflection into the Review, it is wrong.
The Passive Demo Anti-Pattern
| Anti-Pattern Behaviour | Why It Fails | Corrective Coaching |
|---|---|---|
| Slide deck instead of working software | Stakeholders cannot inspect a slide; transparency is lost | Show the running Increment; let stakeholders touch it |
| Product Owner presents alone while Developers watch | Removes the direct question-and-answer path to the people who built it | Developers demonstrate and answer questions themselves |
| Treated as an approval gate where stakeholders "sign off" | Converts a collaboration into a judgement, suppressing honest feedback | Reframe as a working session on what to build next |
| Showing partially complete work "for context" | Undone work misrepresents the state of the product | Only Done work is presented; the rest returns to the Product Backlog |
| Ends when the demo ends | The adaptation half of the event never happens | Reserve the majority of the time for what-do-we-do-next |
The Sprint Review Is Not a Release Gate
One of the sharpest points in the 2020 Scrum Guide: "an Increment may be delivered to stakeholders prior to the end of the Sprint. The Sprint Review should never be considered a gate to releasing value." Multiple Increments may be created within a Sprint, and the sum of them is presented at the Review. Release timing is a Product Owner business decision, not a ceremony milestone.
Real-World CSM Scenario
A Scrum Team's Sprint Review has become a 30-minute slideshow. The Product Owner narrates screenshots, the Developers sit silently, stakeholders ask nothing, and the Product Backlog is never touched during the event.
The Scrum Master's intervention is structural rather than rhetorical: move to a live environment so stakeholders can use the Increment themselves; ask the Developers to demonstrate their own work and field questions; and explicitly reserve the back half of the timebox for the "what should we do next" conversation, ending the event with visible changes to the Product Backlog. When stakeholders see their input change the ordering in front of them, attendance and engagement follow — the incentive to participate is the visible influence, not the invitation.
What is the primary output of the Sprint Review?
During a Sprint Review, the Developers want to show a feature that is functionally complete but has not yet passed the security scan required by the Definition of Done. What should happen?
A stakeholder argues that no Increment may be released to customers until it has been formally approved at the Sprint Review. How should the Scrum Master respond?
Which discussion belongs to the Sprint Retrospective rather than the Sprint Review?