The Sprint Review: A Field Checklist
The sprint review is one of the most misunderstood events in Scrum. Teams often treat it as a demo: a chance to show off what was built before moving on to the next sprint. But the Scrum Guide is specific — it is an inspect-and-adapt event, the moment when the Scrum Team and stakeholders examine the increment and update the product backlog in response to what they learn.
The difference matters. A demo is a presentation. A sprint review is a conversation that changes what the team builds next. Getting that distinction right determines whether the event generates value or becomes a checkbox.
Who Attends and Why It Matters
The Scrum Team — Product Owner, Scrum Master, and Developers — attends. But the event only creates value if the right stakeholders also attend. The Scrum Guide specifies 'key stakeholders': people who have a genuine interest in what was built and who can provide meaningful input on what should be built next.
In practice this means the sprint review should include people who:
Will use the product or represent those who will
Have authority to change priorities or release decisions
Carry domain expertise that can validate whether the increment solves the right problem
Need to coordinate dependent work in other teams or systems
A sprint review attended only by the Scrum Team is not a sprint review — it is a retrospective warm-up. If stakeholders routinely decline to attend, that is a signal worth investigating: the event may not be creating value for them, the cadence may not suit their schedule, or the wrong people have been invited.
Checklist: Preparing for the Sprint Review
Know what to show. Identify the Done items from the sprint — work that meets the Definition of Done — and decide which ones warrant demonstration. Not every story needs to be shown; prioritise the ones that are most relevant to stakeholder decisions.
Know what to defer. Items that are partially done, blocked, or did not reach Done should be clearly acknowledged but not demonstrated as complete. Showing incomplete work as progress erodes trust.
Anticipate the questions. What decisions will stakeholders face based on what you show? What are the likely follow-up questions about roadmap, dependencies, and next steps? Brief the Product Owner in advance so answers are ready rather than improvised.
Prepare the environment. Make sure the demonstration environment is stable, the data is appropriate (not production data, not blank placeholders), and the flow through the product makes sense to someone seeing it for the first time.
Have the backlog ready. The Product Owner should arrive with the product backlog in a reviewable state — prioritised, with the next sprint's candidate items visible — because the review conversation will produce backlog updates.
Running the Review
Open with context: what was the goal of the sprint, and what did the team learn or achieve? This frames the demonstration as purposeful rather than a tour of features.
Show working software. Stakeholders should interact with or observe the actual product in a realistic context, not a curated slide deck. The increment should speak for itself; heavy narration often signals that the product needs explanation it should not require.
Gather feedback actively. Ask specific questions: Does this solve the problem you described? What is missing? What would make this more useful? Silence in a sprint review is not agreement — it usually means the wrong people are in the room or the event does not feel like a safe space for candid input.
Update the backlog in the room. As feedback arrives, the Product Owner should visibly update priorities, add new items, and remove or defer items that no longer make sense. The backlog at the end of the review should reflect what was learned in the meeting.
Anti-Patterns to Avoid
The slide deck review: Showing screenshots or wireframes instead of working software. If it is not done, do not show it as if it is.
No stakeholders: A sprint review without external input is just a team meeting with a different name.
Treating it as a sign-off: The sprint review is not a gate. Stakeholders do not 'approve' the increment; they inspect it and provide input. Framing it as approval creates a compliance mindset rather than a collaborative one.
Rushing through the items: Teams that have too many items to show in a timebox likely planned too much in the sprint, or are demonstrating things that do not warrant stakeholder attention.
No backlog update: If the backlog looks identical before and after the review, the event produced no actionable output.
The sprint review works when it is treated as a genuine opportunity to learn what the market, the users, and the organisation actually need next — not as a performance of progress. Teams that run it well tend to build better products, not just faster ones.
XNM Consulting helps organisations adopt and scale agile ways of working that deliver real results. Learn more about our programme and project delivery services.