The Sprint Review is where the Scrum Team and its key stakeholders inspect the results of the Sprint together and work out what should happen next. It is the second to last event of the Sprint, timeboxed to a maximum of four hours for a one month Sprint and usually shorter for shorter Sprints.
Candidates usually arrive expecting a gate, because most delivery processes have one somewhere near the end. Scrum puts no gate here. Work that reaches the review already meets the Definition of Done, because the Scrum Team applies that standard while the Sprint is running, so the four hours go on deciding what to build next.
What the Sprint Review inspects
The Scrum Team presents the results of its work, and progress towards the Product Goal is then discussed against that evidence. A plan says what the team expected to have built, while a working Increment shows what it has, so the conversation runs on the Increment.
Attendees also review what has changed outside the team since the last review, because the environment moves the next Sprint as much as the Increment does. A competitor may have shipped the same feature, a payments regulation may have changed what the checkout has to capture or the thing customers keep asking for may have shifted. Any of the three alters what the next Sprint should contain.
Out of that comes a decision about what to do next, and the Product Backlog is adjusted to reflect it. That adjustment is the real output of the event, so the honest test of a Sprint Review is whether the backlog looks different afterwards. If it does not, either the team learned nothing or nobody wrote the learning down.
The Sprint Review is a working session and never a sign off
Nothing in Scrum makes the Sprint Review a sign off. An item becomes Done the moment it meets the Definition of Done, and the Scrum Team applies that standard while it works, so the question of whether the work counts is settled during the Sprint and never at the review. The Increment may well have been released days earlier, since Scrum allows work to reach stakeholders as soon as it meets the standard.
Treating the event as approval creates a queue. Finished work waits for somebody to approve it, the feedback that would have changed it arrives after it is built, and the team has spent a Sprint on something nobody looked at until the end. A payments API released behind a flag in week one collects two weeks of reactions from the teams that will call it. The same API held back for approval gets its first reaction at the review, by which point the Sprint it could have changed is over.
What the four hour timebox protects
Four hours is a maximum for a one month Sprint, and the event scales down with Sprint length so that the ratio of inspecting to building stays roughly constant. A review that achieves its purpose in ninety minutes is finished at ninety minutes.
That ceiling protects the stakeholders as much as the team. A review long enough to walk through every item in the Sprint Backlog will be filled that way, and the people whose attention the team most needs then stop coming. A short pass over the work that bears on the Sprint Goal and the Product Goal leaves the rest of the time for what to do next, which is the shape of a review stakeholders keep coming back to.
Who attends the Sprint Review and who decides
The Scrum Team attends and key stakeholders are invited. The test of a key stakeholder is whether the person in the room can change the next decision or is only being kept informed, and that judgement is the Product Owner's.
Collaboration on what to do next is genuine, and the ordering of the Product Backlog afterwards remains the Product Owner's accountability. Stakeholders influence that ordering, but they do not vote on it. When a Product Owner reorders the backlog to match whoever spoke loudest, they have given the decision away, which is a different act from collaborating on it.
What the Scrum Master does at the Sprint Review
The Product Owner's accountability for the ordering settles who decides, and it leaves open what the Scrum Master does in the room, which is the part candidates most often answer wrongly. The Scrum Master ensures the event takes place, keeps it inside its four hours and keeps its purpose clear to everyone attending. None of that makes the Scrum Master the presenter, because the Scrum Team presents the results of its work, and the Developers who wrote the code are the people who can answer a question about it.
Two failures follow from reading the service too widely. When a Scrum Master demonstrates the Increment on the Developers' behalf, the Scrum Master is standing between the people who did the work and the people reacting to it, which weakens the inspection the event exists for. If the event drifts towards a sign off, saying so is the service, because the Definition of Done had already settled that question days before anybody entered the room.
What Scrum leaves open
Almost everything else about the event is left to the Scrum Team. There is no prescribed agenda, no required format and no rule about who does the talking, and three choices come up most often.
- Whether stakeholders try the product for themselves.
- Whether the Developers or the Product Owner walk through the work.
- Whether the team gathers a satisfaction measure afterwards.
None of the three appears in the Guide, so two teams may answer them differently and both be doing Scrum. The Guide fixes two things only. The results are inspected with the people affected by them, and the Product Backlog may change as a result.