Sprint Review — Agile Techniques Library

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.

Informal by design. The Scrum Guide deliberately avoids prescribing a formal structure so the conversation can flow naturally around the work itself.

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.

Tip: Even if the team delivered zero items, still run the Review. The resulting conversation about impediments and changed circumstances is often the most valuable one.

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.

Local note: Te Reo Māori protocols or whakawhanaungatanga may open or close the session in some organisations. Respect the local tikanga and factor it into timeboxing.

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.