Sprint Review
A Scrum ceremony held at the end of each Sprint where the team demonstrates the working increment to stakeholders and collects feedback. Unlike a status report, the Sprint Review is a collaborative working session — stakeholders inspect what was built, ask questions, and influence the product backlog based on what they see.
Copione di facilitazione
- 1
Open by restating the Sprint Goal and what the team committed to, then say plainly what is Done and what is not, and why. Frame the session: 'This is a working session, not a presentation — interrupt, ask questions, and tell us what you would change.'
5 min - 2
Have the developers demonstrate the increment — each person shows the work they built, in the real product, following a realistic user journey rather than a feature checklist. No slides, no mock-ups, nothing that is not Done.
20 min - 3
Hand over the controls: let stakeholders try the product themselves where practical, and capture every question, reaction, and suggestion visibly on a board as it happens. Ask the quiet attendees directly: 'What would you use this for? What is missing for that?'
10 min - 4
Shift to the backlog conversation, led by the Product Owner: 'Given what you have just seen, what should we prioritise next?' Walk through the top of the backlog and adjust openly — items moving up or down in front of stakeholders is the review working as intended.
10 min - 5
Zoom out briefly: share anything that has changed in timeline, budget, or market since the last review, and give a realistic forecast of what the next sprint is likely to focus on.
5 min - 6
Close by reading back the captured feedback, confirming which items enter the Product Backlog and which are consciously parked, and thank stakeholders specifically for the input that changed something.
5 min
Suggerimenti
The Sprint Review is not a formal sign-off meeting — it's a conversation. Keep it collaborative.
Only show working software. Demonstrating incomplete features erodes trust.
Invite real users, not just internal stakeholders, whenever possible — their feedback is more valuable.
Timebox strictly: 1 hour per week of Sprint length (max 4 hours for a month-long Sprint).
Errori comuni
Turning the review into rehearsed slideware — a polished presentation invites applause instead of inspection, and the team stops learning anything it did not already know
Letting the Scrum Master or Product Owner do all the demonstrating while the developers sit silent — the people who built the work answer questions better and grow from the direct contact
Ending after the demo and skipping the backlog conversation — inspection without adaptation is half a review, and the feedback loop the event exists for never closes
Capturing feedback nowhere — stakeholders notice within two or three sprints that their comments vanish, and they stop coming
Variazioni
Remote Sprint Review: use screen share + a Miro board where stakeholders drop sticky notes as they watch the demo. Async variant: record a Loom demo, collect written feedback via form, then hold a 30-min discussion session.
Casi d'uso
Quando usarlo
Closing each sprint with the stakeholders whose priorities actually shape the product backlog — the review is the team's built-in moment to inspect the increment together
Stakeholders keep being surprised at release time — regular reviews of working software replace big-bang reveals with small, correctable course adjustments
Backlog priorities are being argued from opinion and hierarchy — feedback gathered while stakeholders click through a real increment is harder to dismiss than meeting-room speculation
A team is drowning in status-report meetings — one well-run review with a live product demo replaces slide decks and gives stakeholders something they can actually react to
Quando non usarlo
Nothing reached Done this sprint — demonstrating half-finished work erodes trust; hold a short, honest conversation about what happened and take the deeper analysis to the retrospective
As an acceptance gate where stakeholders sign off on work — acceptance against the Definition of Done happens during the sprint; turning the review into a formal approval ceremony makes teams rehearse theatre instead of inviting inspection
For the team's internal process discussion — how the sprint felt, what to improve in how you work — that conversation belongs in the Sprint Retrospective, without stakeholders in the room
When no attendee can influence the backlog — a review for passive spectators is a demo, not an inspection; record a short walkthrough video instead and save the live session for people whose feedback changes what gets built
Metodi correlati
Approfondimenti
Domande frequenti
How long should a sprint review be?▾
A useful rule of thumb is one hour of review per week of sprint, with the Scrum Guide capping it at four hours for a month-long sprint. For the one- and two-week sprints most teams run, 30–60 minutes is realistic: roughly half for the demonstration and half for the feedback and backlog conversation.
Who should attend a sprint review?▾
The whole Scrum team plus the stakeholders who can act on what they see — sponsors, key users, and anyone whose feedback should shape the backlog. It works from a handful of people up to around 30; whenever possible invite real users, whose reactions are worth more than another round of internal nodding.
What is the difference between a sprint review and a sprint retrospective?▾
The review inspects the product with stakeholders — what was built, what feedback it earns, what the backlog should look like next. The retrospective inspects the process within the team — how the sprint went and what to improve in the way of working. They are separate events with different audiences, and merging them usually kills the candour both need.
How do you run a sprint review remotely?▾
Share the live product on screen — not slides — and pair it with a shared board where stakeholders drop sticky-note feedback as they watch, so comments are captured without interrupting the flow. For distributed stakeholders, an async variant also works: record a short demo video, collect written feedback via a form, then hold a 30-minute live discussion on the responses.
What should you prepare for a sprint review?▾
Confirm which items actually meet the Definition of Done, agree who demonstrates what, and dry-run the demo path once in a stable environment so the session is not spent debugging. Beyond that, preparation should be light — an over-produced review is a warning sign that inspection has turned into performance.
Pianifica il tuo prossimo workshop con l'IA
Workshop Weaver ti aiuta a combinare metodi come Sprint Review in un'agenda completa e temporizzata in pochi minuti.
Prova gratisMethod descriptions on Workshop Weaver are original content written by our team, based on established facilitation practices. This method was inspired by work from Scrum Guide.