Sprint Review
A working session held at the end of the sprint where the team presents the completed increment to stakeholders to inspect outcomes, gather feedback, and adapt the Product Backlog.
What it is
The Sprint Review is not a demo. It is an informal working session where the Scrum Team and stakeholders collaborate to inspect the Increment and adapt the Product Backlog.
- The entire Scrum Team and key stakeholders attend.
- The Product Owner reviews what was completed and what was not completed.
- The Development Team demonstrates working software and answers questions.
- The group collaborates on what to do next based on what was learned.
When to use it
Hold a Sprint Review at the end of every sprint. It is a timeboxed event (maximum four hours for a one-month sprint; proportionally less for shorter sprints) and is one of the five formal Scrum events.
Key concepts
| Concept | What it means |
|---|---|
| The Increment | The sum of all Product Backlog items completed during the sprint, plus the value of all previous increments. It must be "Done" and usable. |
| Product Goal progress | The team discusses progress toward the Product Goal, inspects how the marketplace or use context may have changed, and adjusts course. |
| Adapting the Backlog | The outcome is an updated Product Backlog that reflects new insights, re-prioritisations, and newly discovered work. |
| Informal vs Formal | Unlike a stage-gate sign-off, the Review is collaborative. Stakeholders are active participants, not an audience. |
Demo Best Practices and Anti-Patterns
Best practices:
- Show real data. Use production-like data, not toy examples. "Here's a real customer scenario" resonates more than "imagine this scenario."
- Let stakeholders drive the demo. "What would you like to see?" gives them ownership and surfaces priorities.
- Be honest about what is incomplete. "This part works, but we punted error handling to next sprint" shows integrity.
- Prepare one or two failures. Demo what broke and how you fixed it. Shows problem-solving, builds confidence.
- Time-box each story demo. 2-3 minutes per story. More than that and people zone out.
Anti-patterns:
- Reading from slides. "Here's a feature" bores everyone. Demo the feature instead.
- Only senior developers presenting. Junior developers learn by presenting. Give everyone a turn.
- Demos on a slow laptop with laggy internet. Nothing kills a review faster than technical failures. Practice on staging beforehand.
- No engagement. Monologue without questions kills the inspect-adapt loop. Ask: "Does this solve your problem?" and listen.
Stakeholder Engagement Strategies
- Invite the right people: Customers, product managers, leadership, support. Mix business and technical stakeholders.
- Send agenda in advance: "Sprint Goal was X. We completed A, B, C. We didn't complete D because Z. Come ready to discuss next priorities."
- Live demo, not pre-recorded. Live shows real problems; pre-recorded hides them. Stakeholders trust live more.
- Ask for feedback explicitly. "Does this solve your need?" "What would you change?" "What should we prioritise next?"
- Capture feedback in the backlog immediately. Assign someone to write stories during the review based on feedback. Stakeholders see their input convert to work items immediately.
Feedback Collection and Acting on It
During the review: Appoint a scribe to capture feedback on a visible board or document. Label feedback as: "Praise," "Problem," "Suggestion," "Priority." This helps the team hear and prioritise.
After the review:
- Product Owner synthesises feedback: "Stakeholders loved the new dashboard but want export to CSV. Nobody mentioned the report redesign."
- Product Owner adjusts the backlog: Raise CSV export priority, deprioritise report redesign.
- Team commits to next sprint based on adjusted priorities.
Follow-up: In the next Review, reference previous feedback: "Last sprint you asked for CSV export. Here it is." Shows that feedback was heard and acted on.
Real Example: Demonstrating a New Payment Flow
Story: "Add one-click checkout using saved cards"
Demo script:
- Show the old flow: "Previously, users had to re-enter card details every time. It took 2 minutes."
- Show the new flow: "Now, returning customers see 'Use my saved card' by default. One click and done. 10 seconds."
- Live test: Click through from product page to payment, use a saved card, get receipt. All in 30 seconds.
- Show the safety: "We store the card securely via Stripe, not on our servers. If we get hacked, cards are safe."
- Ask: "Does this solve the checkout friction you mentioned last sprint?" (Listen for feedback.)
- Mention what's not done: "We punted email notifications of payments to next sprint, and international cards need more testing."
Why this works: Stakeholders see the problem being solved (faster checkout), trust it's secure, understand what's next. They feel heard and involved.
Virtual Sprint Review Considerations
- Video on. People zone out in audio-only meetings. Seeing faces keeps engagement high.
- Share screen, not slides. Live demo of the product beats a PowerPoint. If something goes wrong, you can troubleshoot live.
- Use chat for questions. Don't wait for unmute. Parallel chat while demoing keeps people engaged.
- Record it. People miss meetings. A recording is available for asynchronous review.
- Shorter timebox. Virtual meetings fatigue faster. If your sprint review was 1 hour in person, try 45 minutes virtual.
Common pitfalls
- Treating it as a "dog and pony show": One-way presentations kill the inspect-and-adapt loop.
- Hiding incomplete items: Transparency builds trust. Show the real state of the Increment.
- Stakeholders treating it as UAT: User Acceptance Testing is a separate activity; the Review is about collaboration, not sign-off.
- Failing to adapt the backlog based on feedback: If the Product Backlog is not updated, the event was wasted.
- Skipping it: Cancelling the Review removes a critical feedback loop and reduces transparency.
- Poor demo execution: A buggy demo or laggy connection undermines confidence in the work shown.
NZ context
In New Zealand, the Sprint Review is often a critical transparency event for government clients and funding bodies. Many public-sector projects operate under tight oversight and reporting requirements. A well-run Review demonstrates progress without requiring separate heavyweight status reports, and it gives stakeholders direct visibility into how budget is translating into working product.
Career level guidance
| Level | Focus |
|---|---|
| Grad | Observe the flow, take notes, and understand the purpose of the event. Prepare one or two questions about the work shown. |
| Junior | Actively participate in demonstrations. Ask clarifying questions and capture feedback for the Product Owner. |
| Senior | Lead demonstrations of complex features, facilitate stakeholder discussion, and help the team stay honest about what is truly "Done." |
| Test Lead | Validate increment readiness before the Review, ensure quality metrics are visible, and surface risks that may affect the next sprint. |
Industry Reality
- In many organisations the Sprint Review quietly becomes a one-way demo to management — stakeholders receive a pre-rehearsed script and never ask questions. Senior practitioners actively resist this by opening with "What do you want to see?" rather than launching into a prepared slide deck.
- Backlog refinement that should happen during the Review rarely does. Product Owners collect feedback, disappear, and resurface a day later with updated priorities. The inspect-and-adapt loop is real, just slower than the Scrum Guide implies.
- In New Zealand government projects (CoverNZ, Benefits NZ, Revenue NZ, DHBs), the Sprint Review is often conflated with formal steering-committee reporting. Teams end up maintaining two artefacts — the live demo and a written status report — doubling effort with no extra value delivered.
- Cross-functional teams on SaaS products often skip the Review entirely for "no-user-facing" sprints (infrastructure, tech debt). The conversation that gets skipped — "are we still pointed at the right goal?" — is often the most valuable one missed.
- Globally distributed teams (common in NZ tech companies with offshore dev) run Reviews asynchronously: a recorded Loom-style demo plus a Slack thread for feedback. It works better than a 6 a.m. Zoom call, but nuance in stakeholder body language is lost.
Context guide
How the right level of Sprint Review effort changes based on team context.
| Context | Priority | Why |
|---|---|---|
| NZ government digital service (e.g. TransitNZ, HealthNZ, CoverNZ) with funding-body oversight | Essential | Funding bodies and steering committees require visible progress evidence. A well-run Review replaces separate written status reports and keeps governance stakeholders directly informed without doubling effort. |
| High-complexity product with multiple business units as stakeholders (e.g. Revenue NZ integrating myIRD, third-party tax agents, and internal policy teams) | Essential | Misaligned priorities between business units compound rapidly when hidden. The Sprint Review is the primary mechanism to surface conflicting needs before they become expensive rework mid-delivery. |
| Early-stage product or MVP where scope is still being validated with real users | Essential | Assumptions about user need are untested. Every sprint is a hypothesis. The Review is the structured moment where reality corrects the roadmap — skipping it means building on unvalidated assumptions for weeks. |
| Established SaaS team with continuous deployment and direct user analytics (e.g. TeleNZ digital product team) | Medium | Continuous deployment means stakeholders can inspect the product in production at any time, reducing the "reveal" value of the ceremony. The Review still matters for backlog alignment and business direction conversation, but format can be lighter — async loom plus a short live discussion. |
| Infrastructure or platform team with no external user-facing features this sprint (e.g. Kubernetes migration, CI pipeline rebuild) | Medium | Nothing to demo as working software, but the strategic alignment conversation ("are we still prioritising this migration over feature work?") must still happen. Run a shorter session focused on metrics and next-sprint direction rather than a live demo. |
| Tightly co-located team with a Product Owner embedded full-time who reviews work daily with stakeholders | Low | When stakeholder feedback is continuous and the Product Owner has real authority to adapt the backlog daily, the formal sprint-end ceremony duplicates work already done. A 15-minute sync to confirm priorities is usually sufficient. |
Trade-offs
What you gain and what you give up when you adopt Sprint Review.
| Advantage | Disadvantage | Use instead when… |
|---|---|---|
| Creates a structured, recurring moment where business stakeholders and the delivery team are in the same conversation about priorities — difficult to replicate through email threads or status reports. | In practice, the event frequently becomes a one-way demo to management who attend out of obligation rather than genuine curiosity. Without the right invitees and a skilled facilitator, the inspect-and-adapt loop does not fire. | Stakeholders have continuous access to the product in staging and the Product Owner has daily direct feedback from end users. Replace with a brief weekly direction check-in. |
| Demonstrates working software over written reports, building genuine stakeholder confidence. A successful live demo of a TransitNZ public transport booking flow is more persuasive than any slide deck. | Live demos on unstable environments can catastrophically undermine confidence — a crash mid-sprint-goal signals the whole increment is fragile, even when only the demo environment has the problem. Preparation overhead is non-trivial. | The team is in a stabilisation sprint with no new features to show. Use the timebox instead to discuss production metrics, resolved incidents, and quality improvements. |
| Backlog refinement happens organically as stakeholders react to the working product — priorities become concrete ("I want that export feature next sprint") rather than abstract ("improve reporting"). | Without a live scribe writing backlog items in real time, stakeholder feedback evaporates. Context and nuance are lost between the verbal comment and the ticket created two days later by the Product Owner working from memory. | The team's backlog is already fully refined with well-understood priorities and stakeholders are highly aligned. A brief async update suffices. |
| Satisfies NZ government transparency requirements (Treasury Better Business Cases, OAG reporting) without requiring a separate written status report — the event itself is the evidence of progress. | When government agencies (Benefits NZ, Revenue NZ, FamiliesNZ) treat the Sprint Review as a formal acceptance gate rather than an inspection event, it degenerates into high-stakes theatre — stakeholders withhold exploratory feedback to avoid creating formal commitments. | Governance requires formal sign-off artefacts that cannot be substituted by an informal working session. In that case, run the Review for collaboration purposes and maintain a separate, lightweight acceptance record. |
Enterprise reality
How Sprint Review changes at 200–300-developer scale in NZ
- At organisations like Pacific Bank and Revenue NZ, Sprint Reviews feed automated release-gate dashboards — test coverage, DAST scan results, and change-advisory records are pulled in before the meeting starts, so the conversation focuses on risk sign-off rather than manually demoing features to stakeholders who already have preview access.
- Compliance reviews become a standing agenda item: Privacy Act 2020 obligations (data minimisation, consent logging) and NZISM controls are checked against each increment, and anything touching payment flows triggers a PCI DSS scope review before the sprint is accepted.
- At 10+ squads, tooling replaces coordination — Jira filters or an internal release-readiness portal aggregate squad velocity, unresolved bugs above severity threshold, and dependency flags; the programme lead reviews the aggregated view rather than sitting in every squad's review.
- Stakeholder logistics harden significantly: a shared Outlook calendar series, recorded demos uploaded to Confluence within 24 hours, and a written sprint summary sent to a business-owner distribution list replace ad-hoc invitations — verbal-only outcomes are considered undocumented and do not satisfy internal audit trails.
◆ What I would do
Professional judgment — when to adopt Sprint Review fully, when to adapt it, and what to watch for.
The bottom line: The Sprint Review is only as valuable as the authority in the room. Every structural improvement to the format — better demos, tighter timeboxing, live scribing — is wasted if the people who can actually change the Product Backlog are not present and engaged.
Best Practices
- ✓ Confirm "Done" before the room fills up. Walk through the Definition of Done with the team the morning of the Review — discovering a story isn't actually done mid-demo destroys credibility.
- ✓ Open with the Sprint Goal, not the story list. "We set out to reduce checkout drop-off by 15%. Here's what we built and whether we moved that needle."
- ✓ Use production or production-like data. Demo on staging with anonymised real data — it surfaces real edge cases and shows the system handles realistic load.
- ✓ Rotate who presents. Grad and junior team members presenting builds their confidence, keeps seniors honest, and stops the Review becoming a one-person show.
- ✓ Appoint a live scribe. Someone writes feedback directly into the Product Backlog (as draft stories or notes) while stakeholders speak. Backlog items appear in real time, not two days later.
- ✓ Name what you didn't complete and why. "We pulled this story but didn't finish it because the API contract changed mid-sprint." Transparency here builds more trust than pretending everything is fine.
- ✓ Close with an explicit next-priority question. "Given what you saw today, what is the single most important thing for us to tackle next sprint?" Forces stakeholders to actively shape the backlog.
- ✓ Circulate a 3-sentence summary afterward. Stakeholders who missed it get a fast digest — Sprint Goal status, key demo outcomes, top 2 backlog adjustments. Keeps absent decision-makers in the loop without requiring a full replay.
Common Misconceptions
❌ Myth: The Sprint Review is where stakeholders approve or reject the work (a UAT sign-off gate).
Reality: The Sprint Review is an inspection-and-adaptation event, not a sign-off ceremony. Acceptance of work against acceptance criteria happens continuously throughout the sprint — often between the developer and the Product Owner. Treating the Review as a UAT gate creates a waterfall checkpoint inside Scrum and delays feedback by weeks.
❌ Myth: If you demo it and nobody objects, the stakeholders are happy.
Reality: Silence in a Sprint Review usually means confusion or disengagement, not satisfaction. Stakeholders often don't know what questions to ask in a live demo setting. Experienced facilitators create structured prompts — "Does this solve the problem you described in the kick-off?" — to draw out real reactions before the meeting ends.
❌ Myth: A polished, rehearsed demo is the mark of a high-performing team.
Reality: An over-rehearsed Sprint Review trades authenticity for theatre. Stakeholders are impressed by real-time problem-solving ("let me show you what happens when you enter an invalid date") far more than a flawless walkthrough of a pre-canned script. The Scrum Guide deliberately keeps the Review informal so the team can respond to real stakeholder curiosity in the moment.
Senior engineer insight
Teams who get the most from Sprint Review treat it as a product conversation, not a delivery receipt — they walk in with the Sprint Goal framed as a question, not an achievement. The pattern that actually separates high-performing teams is having someone on the team explicitly own the stakeholder experience beforehand: confirming the demo environment is stable, seeding stakeholders with one or two focused questions, and keeping a live scribe capturing backlog items as they're spoken. Without that preparation, even good software gets underwhelming reactions because stakeholders don't know what to look for.
The most common mistake: teams spend the week before the Review polishing the demo script instead of verifying the staging environment actually matches production — and then the demo crashes mid-sprint-goal, destroying credibility they spent two weeks building.
From the field
A Wellington-based digital agency team building a case management system for a Crown entity had been running Sprint Reviews for six months and assumed stakeholders were happy — feedback was always polite and the Product Owner left each review satisfied. Then a new programme director joined and attended her first review. She sat quietly through the demo, then asked a single question: "Which of these features has anyone in the actual case management team used?" The silence was devastating. The team had been demonstrating to middle managers who had no visibility of operational pain points, while frontline staff — who processed 200+ cases a week — had never been in the room. The team restructured the invite list, moved the Review to the office where caseworkers actually sat, and within two sprints were getting specific, high-value feedback that completely reordered the backlog. The lesson: who is in the room determines the quality of feedback more than anything else about how you run the session.
Why teams fail here
- Demoing on an unstable environment. Teams skip pre-Review environment checks and the demo breaks on a live stakeholder call — a crashing demo signals the whole increment is unreliable, even if the code is solid.
- Inviting the wrong stakeholders. Product managers and programme directors attend while the people with actual domain knowledge — frontline staff, end users, operational leads — never see the product. Feedback is polite but useless.
- Not updating the backlog in the room. Feedback is collected in a notebook or verbal summary, then handed to the Product Owner who "updates the backlog later" — by which point context and nuance are lost, and stakeholders notice their suggestions don't appear in the next sprint.
- Conflating the Review with a UAT sign-off gate. When NZ government teams use the Sprint Review as the formal acceptance checkpoint, every demo becomes high-stakes theatre, stakeholders stop asking exploratory questions, and the inspect-and-adapt loop collapses into a pass/fail ceremony.
Key takeaway
A Sprint Review done well is not a showcase of what the team built — it is a structured conversation that changes what the team builds next.
Self-Check
Click each question to reveal the answer.
Q: What is the primary purpose of the Sprint Review, and how does it differ from a simple status report?
A: The Sprint Review is an inspect-and-adapt event where the team and stakeholders collaboratively examine the Increment and update the Product Backlog based on what was learned. A status report is a one-way information transfer; the Sprint Review is a two-way conversation that actively reshapes priorities.
Q: What is the maximum timebox for a Sprint Review in a four-week sprint?
A: Four hours. For shorter sprints the timebox is proportionally shorter — for example, a two-week sprint would aim for around two hours. The timebox prevents the event from expanding into an all-day meeting and keeps the team focused on the most valuable feedback.
Q: Why should a team still run a Sprint Review even if zero backlog items were completed?
A: The conversation that happens when nothing was delivered — around impediments, changing requirements, or misaligned expectations — is often the most valuable feedback loop in the sprint. Skipping it removes transparency and prevents the team and stakeholders from addressing the root cause of the underdelivery.
Q: What is one sign that a Sprint Review is being run as an anti-pattern rather than as intended?
A: If stakeholders are silent and passive throughout, receiving a polished, pre-rehearsed presentation with no opportunity to ask questions or redirect priorities, the Review has become a "dog and pony show." The inspect-and-adapt loop has been broken — feedback is not being collected, and the Product Backlog will not be meaningfully updated.
Q: How does the NZ public-sector context (e.g. Revenue NZ, Benefits NZ, CoverNZ) affect how Sprint Reviews are run in practice?
A: Government projects often operate under formal oversight and funding-body scrutiny, so teams frequently maintain two parallel artefacts — a live Sprint Review demo and a written status report — doubling effort. Skilled practitioners advocate for the Sprint Review to replace the status report by inviting the right stakeholders directly, so the event itself satisfies reporting obligations without a separate document.
Q: Your team is building a new myIRD self-service portal feature for individual taxpayers. Stakeholders are a mix of Revenue NZ policy advisors and the product manager. How would you structure the Sprint Review demo to get genuinely useful feedback from both groups?
A: Open with the Sprint Goal framed in user language ("We wanted taxpayers to update their bank account details without calling the contact centre"). Demo the full user journey with realistic anonymised data, calling out the policy constraint that drove each design decision — this gives policy advisors the context they need to respond meaningfully. After each story, ask a direct question: "Does this meet the intent of the policy?" for advisors and "Does this reduce call volume as expected?" for the product manager. Assign a live scribe to convert spoken feedback into draft backlog items in real time.
Q: What is the key difference between the Sprint Review and the Sprint Retrospective?
A: The Sprint Review is an external-facing event that inspects the Increment (the product) and adapts the Product Backlog based on stakeholder feedback. The Sprint Retrospective is an internal-facing event that inspects the team's process and collaboration (how we work), producing improvement actions for the next sprint. The Review answers "are we building the right thing?"; the Retrospective answers "are we working in the right way?"
Q: A developer on your team says, "We don't need a Sprint Review — we've already got sign-off from the Product Owner on each story throughout the sprint." What is wrong with this reasoning and how do you respond?
A: Story-level acceptance between the developer and Product Owner confirms that individual items meet their acceptance criteria, but it doesn't replace the Sprint Review's broader purpose: showing the integrated Increment to real stakeholders, checking progress toward the Product Goal, and adapting the backlog based on what the market or business has learned during the sprint. Without the Review, key stakeholders lose visibility, and the team loses the feedback signal that keeps them building the right thing. In NZ government contexts especially, this can leave funding bodies and governance committees completely uninformed about actual progress.
How this has changed
The field moved. Here is how Sprint Review evolved from its origins to current practice.
The Sprint Review (then called Sprint Demo) is one of Scrum's original events. Teams demonstrate working software to stakeholders at sprint end to create transparency and gather feedback.
Distinction between Sprint Review (inspect the product) and Sprint Retrospective (inspect the process) is formalised. Teams that conflate the two events skip the process improvement focus.
Sprint Review evolves from a "demo" to a collaborative working session. Stakeholders interact with the product rather than just watching a presentation.
Continuous deployment makes the Sprint Review less of a "reveal" event — stakeholders can inspect continuously deployed software at any time.
Some teams replace formal Sprint Reviews with continuous stakeholder access via feature flags and preview environments. Others retain the ceremony for its alignment value. AI tools can auto-generate highlights from ticket completion data and production metrics.