Sprint Review

Purpose

The Sprint Review is an inspect-and-adapt event at the end of each Sprint. The team shows what was accomplished, stakeholders provide feedback, and the Product Backlog is updated to reflect new insights. It is a working session, not a formal presentation.

At a glance

How to run

1. Welcome & context (5 min) — Product Owner recaps the Sprint Goal and which items were completed vs. not completed.
2. Demo (25 min) — Developers demonstrate working increments. Show real software, not slides. Invite stakeholders to interact.
3. Feedback round (15 min) — Stakeholders share reactions, ask questions, and suggest changes. Capture everything visibly.
4. Backlog update (10 min) — Product Owner and stakeholders discuss how feedback affects upcoming priorities. Reorder or add items.
5. Close (5 min) — Summarize decisions and next steps. Confirm the next Sprint Planning time.

Materials needed

• Working product increment (deployable or staging environment)
• Product Backlog (visible to all)
• Feedback capture board (sticky notes, Miro, or shared doc)
• Projector or screen share

Pitfalls & common mistakes

• Slide-ware instead of working software — Demo the real thing; slides hide reality.
• No stakeholders attend — Without feedback the event is pointless. Actively invite and make it easy for them.
• Team treats it as a sign-off gate — The review is for learning, not approval.
• Skipping the Backlog update — Feedback that does not flow into the Backlog is wasted.
• Only the Product Owner presents — Developers should demo their own work.

Inclusion & accessibility

• Send a short agenda and demo preview 24 hours in advance.
• Provide captioning for remote participants.
• Allow stakeholders to submit feedback asynchronously if they cannot attend live.
• Rotate who demos to build everyone's presentation confidence.

Variations

• Science fair — Set up multiple demo stations; stakeholders circulate freely.
• Video walkthrough — Pre-record short demos for distributed stakeholders in different time zones.
• Combined review + retro — For very small teams, merge the two events into one session.

When NOT to use this

• If no potentially releasable increment exists — the team should explain why, but a review without product to show is hollow.
• If stakeholders are not empowered to give feedback that changes priorities — fix the governance first.

Source & further reading

• Schwaber, K. & Sutherland, J. (2020). *The Scrum Guide*. scrumguides.org
• Pichler, R. (2016). *Strategize*. Pichler Consulting.