How to run a Sprint Review
The most common Scrum meeting that people get wrong is the Sprint Review. I hear people calling it a “demo", a “showcase” or – my pet hate – a “show and tell". This completely fails to achieve the key purpose of the Sprint Review.
In our Professional Scrum Master class, we work through the follow exercise:
The team show the Product Owner and other stakeholders the features working. Everyone is really happy with progress. There is a big round of applause and then everyone goes back to work. What is wrong with this situation?
The answer lies in the three core pillars of Scrum – transparency, inspection and adaption. Every Scrum meeting involves inspecting and adapting. So if we just do a “demo”, we’re inspecting the increment of potentially shipping software. But what are we adapting?
The point of a Sprint Review is to inspect the increment and adapt the Product Backlog. It is a collaborative working session, not a presentation.
The Sprint Review is designed so that all attendees can inspect what has just been done in the current Sprint and then work together to discuss what the next optimal move is for the business. This means discussing the Product Backlog as it currently stands.
Here’s how I run a Sprint Review:
1. Let them know why there’s a Sprint Review
Start by making sure that everyone, including the stakeholders, know the reason for the Sprint Review – that is, it’s a collaborative working session where we will look at working software produced in the last Sprint and then seek perspectives on what we should do next and what might no longer be of value.
2. A team reminder
Remind the team before Sprint Planning that there will be a Review at the end of the Sprint and describe what to expect. They should be able to show:
• an overview of how the Sprint went
• the “done” items as working software
• which items are not done and that they’re now back on the Product Backlog. This is designed to ensure that no hidden work is undone (technical debt)
We will then, along with other business stakeholders, discuss what we should do next.
3. Ask them how they’ll show their work
At some point throughout the Sprint, ask the team if they’ve considered how they’re going to show their completed work. Maybe they’d like to consider a relevant subset of the acceptance tests to do this? Perhaps each team member might volunteer to do one User Story each? Or one team member could volunteer to show all the user stories working?
11. Record the results
Don’t forget to record the main points of what was agreed.
And remember to inspect and adapt.
How do you run a Sprint Review? Tell us about your experiences.