The Sprint Review is a ceremony at the end of each sprint where the team demonstrates completed, working software to stakeholders and collects feedback. It is a feedback loop, not a sign-off ceremony. The backlog is updated based on what is learned.
At the end of every sprint, without exception. The cadence of stakeholder feedback is what makes iterative development actually work.
- Team demonstrates only completed, working software — nothing partially done
- PM recaps the sprint goal and what was achieved vs. committed
- Stakeholders ask questions and share reactions
- PM captures new insights and updates the backlog
- Briefly discuss what's planned for the next sprint
- No slides, no status reports — only working software counts
After a sprint improving the Discover Weekly explanation UI, the team demos the new 'Because you liked' labels to stakeholders including the Head of Discovery. Feedback: 'The label is helpful but users won't understand 'liked' here — they didn't explicitly like it, they just listened a lot.' Vocabulary change from 'liked' to 'listened to' added to the next sprint.
Please contact the author for more information on these examples at linkedin.com/in/kshitijrege
- Demoing non-working software or mockups — this destroys trust and defeats the purpose
- Turning it into a one-way presentation — it should be a genuine conversation with feedback
- Skipping the review when the sprint had problems — that's when feedback matters most
- The Scrum Guide (free)