Purpose: inspect the product, adapt the backlog
The Scrum Guide frames Sprint Review as an inspection of the Increment against the Sprint Goal and the Product Goal, with the whole group collaborating on what to do next. The Product Backlog may be adjusted to meet new opportunities.
That means the value of Sprint Review is not the finished demo, it is the conversation that happens because stakeholders saw something real and reacted to it. If nobody's mind changes about what to build next, the review has not done its job.
Who attends and what each person contributes
The whole Scrum Team attends, along with key stakeholders invited by the Product Owner: customers, users, sponsors, or other teams whose work depends on this product. The Product Owner explains what Product Backlog items have been 'Done' and what has not, and shares the current state of the Product Backlog including forecasted completion dates if asked.
The Developers demonstrate the work they completed and answer questions about it, including problems they ran into and how those were solved. The Scrum Master ensures the event happens, stays timeboxed, and keeps the tone collaborative rather than a performance review of the Developers.
Running a useful Sprint Review
Show only work that meets the Definition of Done. Demoing unfinished work under a disclaimer trains stakeholders to distrust every demo they see.
Anchor the discussion in the Sprint Goal and the Product Goal, not a checklist of tickets closed. Open with what the team set out to achieve, show what was built, then spend real time on stakeholder reaction and market or user changes that might reorder the backlog.
Keep the timebox honest: the Scrum Guide sets a maximum of four hours for a one-month Sprint, proportionally shorter for shorter Sprints. If a two-week Sprint's review regularly needs two hours, something upstream, usually scope or Definition of Done discipline, needs attention.
- Only show Increments that meet the Definition of Done
- Frame the session around the Sprint Goal and Product Goal, not a task list
- Invite the stakeholders whose reaction actually changes decisions
- Leave time to update the Product Backlog based on what was learned
Anti-patterns
The classic failure mode is a scripted, low-risk demo where nothing can go wrong because nothing real is at stake, essentially a status update disguised as inspection. Another is turning Sprint Review into a Developer performance review, which erodes psychological safety and discourages honest demos of partially successful experiments.
A quieter anti-pattern is holding Sprint Review but never actually changing the Product Backlog afterward. If stakeholder feedback never alters what happens next, the event has become theater rather than inspection.
How it connects to the rest of Scrum
Sprint Review only works if the Increment is genuinely Done, so it is downstream of a well-enforced Definition of Done. What gets decided here feeds Product Backlog refinement and the next Sprint Planning, since new insights and re-ordering happen in this conversation.
Frequently asked questions
Is Sprint Review the same thing as a demo?
No, though a demo usually happens inside it. A demo is a one-way presentation of finished work. Sprint Review is a working session where the Scrum Team and stakeholders inspect the Increment together and collaborate on what the Product Backlog should look like next.
How long is Sprint Review?
The Scrum Guide sets a maximum of four hours for a one-month Sprint, shortened proportionally for shorter Sprints, so a two-week Sprint typically gets around two hours. Teams with a tight Sprint Goal and disciplined Definition of Done often need less.
Can unfinished work be shown at Sprint Review?
It should not be presented as part of the Increment. Work that does not meet the Definition of Done is not Done, and showing it as if it were undermines trust in future reviews. If it needs discussion, it can be mentioned as in-progress context.
Who decides what changes in the Product Backlog after Sprint Review?
The Product Owner is accountable for the Product Backlog and makes the final call, but the whole point of Sprint Review is that the decision is informed by the shared discussion during the event, not made in isolation beforehand.