The template
Five-section structure for a 75-minute review
The 75-minute total below sits comfortably under the Scrum Guide's 2-hour ceiling for a 2-week sprint. Adjust each section length proportionally for longer or shorter sprints.
Section 1: Sprint goal recap (5 min)
The product owner states the sprint goal that was committed at sprint planning. Brief recap of what the team was trying to achieve, not what they did. This frames the demo so stakeholders evaluate the increment against the goal, not against arbitrary expectations. Skip the slide deck recap of every committed item; the backlog already shows that.
Section 2: Working software demo (35 min)
The development team demonstrates the completed increment in working software, not slides. Each demo segment includes the user problem being solved, the working flow, and any decisions the team made along the way. Encourage stakeholders to interrupt with questions during the demo, not save them for the end; mid-demo questions surface the most useful feedback because reactions are anchored in what was just seen. Use real data where possible, not lorem-ipsum or canned test cases.
Section 3: Metrics and outcomes (10 min)
Share the product metrics that moved during the sprint: adoption, conversion, performance, error rates. If the sprint goal was outcome-oriented (validate a hypothesis, improve a metric), this is where evidence about whether the goal was achieved gets shared. For early-stage products without metric data, share qualitative signal: customer interviews, support ticket trends, user research findings. Metrics shown in the review with stakeholder visibility create a forcing function for outcome-orientation that backlog-level discussion rarely achieves.
Section 4: Backlog impact discussion (20 min)
Based on what was just seen, what should change in the backlog? The product owner walks stakeholders through the top of the backlog and surfaces the next 2 to 3 sprint goals under consideration. Stakeholders weigh in on priority. The Scrum master captures any new items, scope changes, or priority shifts in real time, so the backlog leaving the meeting reflects the conversation. This section is the heart of the review and the section that teams stuck in status-meeting drift skip entirely.
Section 5: Close (5 min)
Confirm next review date. Note any committed follow-up actions (a separate stakeholder interview, a deeper data analysis, an updated roadmap share). Thank attendees for their time and feedback. The close is short because the work is done in section 4; if the close is taking 15 minutes it is because the backlog discussion is bleeding into it.
Anti-patterns
Four sprint review anti-patterns to avoid
Slides instead of working software
If the team is showing slides of what was built rather than the working product, the increment was not actually done. The discipline of demoing working software is what makes the definition of done real. Slides allow handwaving; working software does not.
Review as status meeting for the manager
When the review exists to update a single senior stakeholder on team progress, the format has been hijacked. That conversation belongs in a separate 1:1 or leadership update. The review exists for stakeholder-to-team dialogue about the product, not team-to-manager status reporting.
No backlog impact captured
If the backlog looks identical after the review as before it, the review did not produce its main artefact. Stakeholders saw the working software, had reactions, but those reactions did not change priorities. Either the team is not actually building the right thing (so feedback should change priorities) or stakeholders did not engage (so the format needs work).
Incomplete work shown to look productive
Showing "almost done" work in the review erodes the definition of done. Stakeholders learn that partial credit is normal, which inflates expectations on future sprints. Only completed work appears in the demo; incomplete items go back to the backlog without ceremony.
Related ceremonies
Sprint review in the Scrum cadence
Sprint planning
The ceremony that opens the sprint, where capacity, goal, and backlog get committed.
Sprint retrospective
The ceremony that follows the review. Five retro formats and when to use each.
Daily standup
The 15-minute daily ceremony that keeps the sprint plan on track between planning and review.
Effective agenda principles
Five elements every agenda needs, anchored in HBR and MIT Sloan research.
FAQ
Common questions about sprint review
How is sprint review different from a demo or status meeting?
Sprint review is a working session, not a presentation. The 2020 Scrum Guide describes it as 'a working session during which the Scrum team and stakeholders inspect what was done and discuss what to do next.' The output is updated backlog priorities and shared understanding, not a deck of completed work. Reviews that feel like status reports have drifted; reviews that feel like working meetings with the product moving in real time are healthy.
Who should attend sprint review?
The Scrum team plus key stakeholders: the people who will use the product, the people who pay for it, and any leaders whose plans depend on what gets built. The 2020 Scrum Guide does not cap attendance, but practical experience suggests 5 to 15 attendees produces real interaction; above 20 the meeting becomes a broadcast and stakeholder feedback dries up.
What if some sprint items aren't complete?
Show only completed (done-done) work in the demo. Incomplete items go back to the backlog for the next sprint and are not demoed. The temptation to show 'almost done' work undermines the definition of done and conditions stakeholders to expect partial credit, which inflates future commitments. The 2020 Scrum Guide is explicit: only completed increments are shown.
How long should sprint review be?
The Scrum Guide caps sprint review at 4 hours for a 4-week sprint and proportionally less for shorter sprints. For 2-week sprints, the cap is 2 hours and most teams run it in 60 to 90 minutes. The cap is a ceiling, not a target. Reviews that consistently hit the cap have either too much to show (a sign the sprint was over-committed) or are drifting into status-meeting territory.
Should stakeholders see incomplete work in any context?
Yes, but outside the sprint review ceremony. Stakeholder previews of in-progress work happen during the sprint via informal demos, design reviews, or shared prototypes. The sprint review is reserved for completed work and forward-looking backlog discussion. Mixing the two diffuses the signal of 'this is what we have committed to and shipped.'
How do you capture stakeholder feedback during a review?
Designate a single note-taker (often the Scrum master) who captures stakeholder reactions verbatim during the demo, distinguishing between feedback on shipped work and requests for new work. The product owner converts requests into backlog items during the meeting if priorities are clear, or marks them for refinement if more discussion is needed. The aim is to leave the review with a backlog that reflects what stakeholders just saw, not three days later when memory has degraded.