This is an excerpt from the new Illustrated Scrum Myths book by Mary Iqbal, now available on Amazon. Each myth in the book includes a full-color illustration, a description of the myth, and an explanation of the truth behind the myth.
The myth
The Sprint Review only demonstrates what the Scrum Team (or Product Team) has accomplished in the last Sprint.
The reality
Yes, many Sprint Review events include a demo, but the Sprint Review is so much more than that.
The Sprint Review is an opportunity to show what was accomplished, request feedback, and collaborate with stakeholders about what to do next. The three pillars of Empiricism are transparency, inspection, and adaptation. The Sprint Review is critical to the team’s ability to inspect honestly and adapt the plan for what to do next.
Here’s why
The misconception that the Sprint Review is merely a demo overlooks its fundamental purpose. While a demo may be a component of the Sprint Review, it represents just one facet of a broader purpose.
During the Sprint Review, the Scrum Team should be open and honest about how the Sprint unfolded, take a collective look at the increment that was delivered, and collaboratively brainstorm potential adaptations for the Product Owner to consider adding to the Product Backlog for delivery in future Sprints.
What this myth reveals
This team’s Sprint Review is boring! Who wants to sit through a one-way communication, Sprint after every single Sprint?
This team may also not recognize that each Sprint is an opportunity to change direction. The Sprint Review is an important opportunity to get feedback so that the Product Owner can decide what to do next.
Do this instead
Make the Sprint Review a two-way communication by asking for feedback. Here are a few questions to consider asking your stakeholders at the Sprint Review. The Product Owner should consider asking a different question at each Sprint Review to keep the creativity flowing.
What do you want to see more of? What do you want to see less of?
How do you see the progress we've made impacting the customer?
What would you change or improve if you were in our shoes?
Which feature or improvement excites you the most, and why?
What’s one thing you would tell someone else about the work we've done this sprint?
Asking questions is great. But what about some activities that could take this even a step further? I wouldn’t do these for every single Sprint Review, but adding a dose of engagement can help prompt more helpful feedback that could impact the team’s future focus. Here are a few activities to consider:
Live Demo with Scenarios. Instead of just presenting completed work, create real-life stories that show the product in action. You could even role-play those stories with audience participation.
Voting. Vote on the most valuable thing delivered in the previous Sprint.
Feedback Carousel. Set up different stations (either physical or virtual) for each significant feature or piece of work completed. Stakeholders rotate through each station, providing specific feedback and suggestions at each one, then regroup to discuss the insights gathered.
Brainstorming. Conduct a brainstorming session and ask stakeholders what they want to see delivered in future Sprints.
Customer Persona Discussions. Tie the Sprint’s work back to specific customer personas. Discuss how the completed features or improvements will benefit those personas.
Try to be mindful of stakeholder’s time and keep it brisk. I recommend sending out an agenda before each Sprint Review to help stakeholders prepare for the Sprint Review.
Conclusion
The Sprint Review is far more than a mere demo—it is a vital part of the iterative, feedback-driven process that underpins successful product development with the Scrum framework.
For more Scrum Myths' get Illustrated Scrum Myths for your Scrum team. This book contains almost 300 pages of advice and over 100 full-color illustrations. Skip around or read it cover to cover.