5.1 Sprint Review
Key Takeaways
- The Sprint Review is held to inspect the outcome of the Sprint and determine future adaptations
- The Scrum Team presents results to key stakeholders and discusses progress toward the Product Goal; the Product Backlog may be adjusted
- The Sprint Review is a working session, not a status presentation or a release-approval gate
- Timeboxed to a maximum of four hours for a one-month Sprint (shorter for shorter Sprints); it is the second-to-last event of the Sprint
- The Product Owner uses stakeholder collaboration and value feedback to adapt the Product Backlog—an Increment may already have been delivered earlier in the Sprint
5.1 Sprint Review
Scrum Guide 2020: The purpose of the Sprint Review is to inspect the outcome of the Sprint and determine future adaptations. 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 this information, attendees collaborate on what to do next. The Product Backlog may also be adjusted to meet new opportunities. The Sprint Review is a working session and the Scrum Team should avoid limiting it to a presentation.
Timebox: The Sprint Review is the second to last event of the Sprint and is timeboxed to a maximum of four hours for a one-month Sprint. For shorter Sprints, the event is usually shorter.
For PSPO I, the Sprint Review is one of the highest-yield events for Product Owner thinking. The exam tests whether you treat it as empirical product management with stakeholders—or as a slide deck, a UAT sign-off, a project status meeting, or a release committee.
Purpose: Inspect Outcome, Determine Adaptations
Two verbs drive the event:
| Verb | What it means in practice |
|---|---|
| Inspect | Look at the outcome of the Sprint—especially the usable Increment(s) and evidence of progress toward the Product Goal—not only task completion percentages |
| Adapt | Decide what to do next based on what was learned inside and outside the Sprint; update product direction via the Product Backlog |
Inspection without adaptation is theater. Adaptation without honest inspection is politics. Empiricism requires both.
Outcome ≠ activity report
“We completed 23 tickets” is activity. “Users can now complete checkout on mobile, and support tickets about cart errors fell 40% in the pilot cohort” is closer to outcome. The Product Owner steers conversation toward value, Product Goal progress, and environmental change—not vanity burndown narratives.
Who Attends and What Happens
Participants
- The entire Scrum Team (Product Owner, Scrum Master, Developers)
- Key stakeholders invited for the product and market context (customers, users, business partners, subject-matter experts—whoever provides useful inspection of value)
The Guide does not prescribe a fixed guest list. “Key stakeholders” means people whose input improves the quality of product decisions—not every executive who wants a status briefing, and not only people who fund the team.
Core flow (Guide-aligned)
- Scrum Team presents results of their work — typically by inspecting the Done Increment (working product), not only screenshots or plans.
- Progress toward the Product Goal is discussed — how this Sprint moved (or failed to move) the long-term objective.
- What changed in the environment is reviewed — competitor moves, regulation, budget, usage data, support load, strategic shifts.
- Attendees collaborate on what to do next — joint exploration of opportunities and risks.
- Product Backlog may be adjusted — new items, reordering, splitting, dropping low-value work, reframing goals.
The Product Owner remains accountable for Product Backlog content and order. Stakeholders influence by providing evidence and perspectives; they do not vote the backlog into a new order over the PO.
Working Session, Not a Presentation
The Guide is explicit: avoid limiting the Sprint Review to a presentation. Presentation-only anti-patterns include:
| Anti-pattern | Why it fails empiricism |
|---|---|
| Slide deck of completed stories with no working product | No real inspection of the Increment |
| One-way demo; stakeholders silent until the end | No collaboration on “what next” |
| PO or SM reads a status report to managers | Replaces product inspection with project reporting |
| Fixed agenda that never discusses environment change | Misses external signals that should reshape the backlog |
| “Any questions?” then meeting ends without backlog adaptation | Inspection without adaptation |
A healthy Sprint Review feels like a collaborative working session: people interact with the Increment, challenge assumptions, surface market facts, and leave with a clearer, possibly reordered Product Backlog direction.
Practical PO facilitation (without turning into a project manager):
- Open with Product Goal context and what the Sprint intended to learn or deliver
- Prefer live product over decks
- Invite stakeholders to react to value, not only aesthetics
- Capture backlog candidates transparently (new opportunities, risks, drops)
- Close by reflecting how the ordered Product Backlog now better matches reality
The Scrum Master helps ensure the event is effective and within the timebox; the Product Owner steers value conversation and backlog implications.
Timebox and Place in the Sprint
| Fact | Scrum Guide 2020 |
|---|---|
| Maximum duration | 4 hours for a one-month Sprint |
| Shorter Sprints | Event is usually shorter |
| Order in the Sprint | Second to last event |
| What follows | Sprint Retrospective (last event), then the Sprint ends |
Exam traps:
- Claiming the Sprint Review is the last event of the Sprint → wrong; Retrospective concludes the Sprint.
- Claiming a fixed minimum length → wrong; the Guide sets a maximum timebox.
- Treating four hours as mandatory for two-week Sprints → wrong; shorter Sprints usually have shorter Reviews.
Product Owner Angle: Collaboration, Feedback, Backlog Adaptation
PSPO I emphasizes three PO-centered outcomes of the Sprint Review:
1. Stakeholder collaboration
The Sprint Review is a primary formal opportunity for stakeholders and the Scrum Team to inspect value together. Between Reviews, collaboration continues; the event concentrates feedback when a Done Increment exists to inspect.
If key stakeholders never attend, the Product Owner still inspects with the team—but missing external signals weakens empiricism. Partner with the Scrum Master to remove barriers between stakeholders and the Scrum Team rather than inventing a separate steering committee that reorders the backlog outside Scrum.
2. Value feedback (not vanity approval)
Feedback should answer: Does this Increment create the value we believed it would? What did users/market/data show? What should we stop, start, or change?
Feedback is not:
- A formal UAT pass/fail that redefines Done after the fact
- A committee vote on whether Developers “get credit” for the Sprint
- A performance review of individuals
3. Product Backlog adaptation
Based on inspection, the Product Backlog may be adjusted to meet new opportunities. That can mean:
- Elevating items that suddenly matter more
- Adding experiments or enablers discovered from stakeholder insight
- Deferring or removing items that no longer serve the Product Goal
- Refining upcoming items with sharper acceptance intent after seeing the Increment
Adaptation is continuous; the Sprint Review is a focused moment when evidence from the Sprint and the environment is most visible.
Not a Release Gate
This is a classic PSPO trap.
Fact: An Increment may be delivered to stakeholders prior to the end of the Sprint. The Sprint Review is not the only moment value can be released, and it is not an approval board required before release.
| Correct | Incorrect |
|---|---|
| Done Increment can be released whenever the Product Owner decides value warrants it | “Nothing ships until the Sprint Review demo” |
| Review inspects what was done (and may discuss releases already made) | Review is a change-control CAB that signs off production |
| Multiple Increments may be created within a Sprint | Only one “big bang” demo at month-end is allowed |
The Definition of Done determines whether work is part of the Increment. The Product Owner decides whether and when to release a Done Increment. Stakeholders at the Sprint Review help inform future value decisions; they do not replace DoD or PO release accountability.
“Acceptance” language to avoid on the exam
If a scenario says the Sprint Review exists so the Product Owner can “accept or reject” work as Done, treat that carefully. Done is established by the Definition of Done as the quality measure for the Increment. The Product Owner clarifies business intent and collaborates on understanding value; turning the Review into a personal accept/reject gate for quality that should already be in DoD is an anti-pattern. Undone work is simply not part of the Increment—regardless of a demo meeting.
Progress Toward the Product Goal
Every Sprint Review should connect the Sprint’s outcome to the Product Goal—the long-term objective for the Scrum Team and the commitment of the Product Backlog.
Useful discussion prompts:
- How much closer are we to the Product Goal than last Sprint?
- Did this Sprint invalidate assumptions in the Product Goal or strategy?
- Should the ordered backlog still aim at the same Product Goal, or has learning forced a rethink?
- What forecast of progress is honest given this Increment and current throughput?
Without Product Goal conversation, Reviews devolve into feature showcases with no strategic thread—exactly the “feature factory” failure mode PSPO I expects you to reject.
What the Sprint Review Is Not (Quick Trap Table)
| Claim | Verdict |
|---|---|
| Status meeting for managers | Wrong — working session on product outcome |
| Only Developers present the work; PO optional | Wrong — whole Scrum Team; PO critical for value/backlog |
| Stakeholders reorder the Product Backlog by vote | Wrong — PO remains accountable for order |
| Mandatory release ceremony | Wrong — release can happen earlier; Review is not the gate |
| Last event of the Sprint | Wrong — Retrospective is last |
| Unlimited length if stakeholders keep talking | Wrong — timeboxed (max 4 hours for one-month Sprint) |
| Replaceable by emailing a demo video | Wrong — collaboration and adaptation need real interaction |
PSPO Scenario Drill
Scenario: Leadership wants a 20-minute slide presentation every Sprint so executives can “approve the release.” Developers stop releasing mid-Sprint. Stakeholders never touch the product.
Sound PO response:
- Re-establish the Sprint Review as a working session inspecting a Done Increment and Product Goal progress.
- Clarify that release decisions can occur when an Increment meets DoD and value warrants release—not only at Review.
- Invite key stakeholders who can provide product and market feedback, not only funding approvers.
- Use the session to adapt the Product Backlog transparently based on evidence.
- Engage the Scrum Master to coach the organization away from presentation theater toward empirical product management.
That single scenario encodes the purpose, attendees, working-session nature, timebox context, PO backlog accountability, and the non-release-gate rule—the full Sprint Review model PSPO I expects.
Quick Self-Check
Before the next section, you should state without notes:
- Purpose: inspect Sprint outcome and determine future adaptations
- Who: Scrum Team + key stakeholders; progress toward Product Goal discussed
- Style: working session; Product Backlog may be adjusted
- Timebox: max 4 hours for one-month Sprint; second-to-last event
- PO focus: stakeholder collaboration, value feedback, backlog adaptation—not a release gate
According to the Scrum Guide 2020, what is the purpose of the Sprint Review?
Which statement about the Sprint Review is correct?
A stakeholder insists that no Increment can be released until it is “approved” at the Sprint Review. What is the best Product Owner response aligned with Scrum?