4.4 The Sprint Review

Purpose of the Sprint Review

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. The attendees are the whole Scrum Team plus key stakeholders invited by the Product Owner — customers, sponsors, users, or other groups whose input shapes direction.

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 — items reprioritized, added, or removed in light of what was learned. The 2020 Scrum Guide stresses that the Sprint Review is a working session and the Scrum Team should avoid limiting it to a presentation.

The Increment under review must already meet the Definition of Done; only Done work is part of the Increment. Work that is not Done is not presented as complete and is not the subject of stakeholder sign-off — it simply remains in the Product Backlog.

Not Just a Demo

A frequent PSM I trap treats the Sprint Review as a demo or formal sign-off meeting where the team shows finished work and stakeholders approve or reject it. The Scrum Guide frames it as a collaborative working session focused on what to do next. A demonstration of the Increment may occur, and often does, but the value of the event is the conversation that adapts the Product Backlog. If an answer says the Review's main job is to "get acceptance" or "present a slideshow," it is wrong; the main job is to inspect the outcome and decide the next steps together.

The Sprint Review is also not the place to accept individual stories one-by-one as a gate. Acceptance against the Definition of Done happens as work is completed during the Sprint, not as a ceremony at the Review. The Review zooms out to the product and the market.

Timebox and Position in the Sprint

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 — about two hours for a two-week Sprint by convention. The Sprint Retrospective follows it and concludes the Sprint.

Review Versus Retrospective

These two closing events are the most commonly confused pair on the exam. Keep them separate by what they inspect and who is in the room:

• Sprint Review looks outward at the product and the Product Backlog, with stakeholders. It inspects the Sprint outcome / Increment and adapts the Product Backlog.
• Sprint Retrospective looks inward at the Scrum Team's process and interactions, without stakeholders. It inspects the team's way of working and plans process improvements.

Both events inspect and adapt — that is empiricism — but on different subjects. A useful test question to ask yourself: Is this about the product, or about how the team works? Product and Product Backlog → Review. People, process, tools, and Definition of Done → Retrospective.

Keeping this distinction sharp answers a large share of event questions on PSM I. When a scenario routes stakeholder product feedback into the Retrospective, or routes team-process complaints into the Review, the answer is to swap them back to the correct event.

What the Sprint Review Is Not

Several PSM I distractors describe activities that resemble a Sprint Review but violate it. The Sprint Review is not a phase gate where a steering committee approves moving to the next stage — Scrum has no phase gates. It is not the moment stakeholders sign a contract accepting scope; Scrum defines no scope-acceptance artifact. It is not where the team first integrates and tests the Increment — the Increment must already be Done and integrated before the Review, because only Done work is part of the Increment.

And it is not optional when "there is nothing to show"; even a Sprint with a small or troubled Increment still holds a Review to inspect the outcome and adapt the Product Backlog. Recognizing these false framings is half the battle on Review questions.

Why the Review Drives Adaptation

The Sprint Review is the framework's primary mechanism for adapting the product direction based on real evidence. By inspecting a Done Increment with the people who care about the product, the Scrum Team converts assumptions into observations: stakeholders react to working software, the market context is updated, and the Product Backlog is reordered or reshaped accordingly. This is empiricism aimed outward. The Product Owner remains accountable for the Product Backlog, but the Review is a collaboration — stakeholders inform, the team and Product Owner decide.

The output is not just "feedback collected" but an updated Product Backlog and shared sense of direction that feeds straight into the next Sprint Planning. A team that treats the Review as a box-ticking demo loses this adaptation entirely, which is why the Guide is emphatic that it is a working session.