Sometimes people call this the demo or the show and tell, but a Sprint Review is much more than a demonstration.
Its primary purpose is to get feedback on the product increment. This is most certainly a two-way conversation between the Scrum Team and the stakeholders/customers who are in attendance. So if its just the team and the Product Owner sat in a room you are probably missing the point. Indeed nothing should be a surprise to the Product Owner, because they should have been involved with the team throughout the Sprint providing feedback. Invite anyone and everyone who is interested in your product, and if nobody shows up, you are probably building the wrong thing.
A secondary purpose of the Sprint Review is to have a look at the bigger picture of the product in relation to the marketplace.
- If you are not releasing at every Sprint, then how many Sprints might we need until it makes sense to release?
- Feedback on the order of the Backlog in relation to the product vision and the needs of customers.
- Review of the market place, has anything changed that impacts what we are doing.
- Have a look at how key metrics are changing based on what the team is delivering, i.e. what’s the impact on the market?
Based on the feedback and the wider conversation about the position of the product in the market place, then the result will be an updated Product Backlog. Maybe even more importantly it results in the alignment of key stakeholders behind what the team is doing.
Finally in terms of purpose; it should also be treated as a time of celebration, to celebrate the achievements of the team, especially when it has gone particularly well.
In terms of format, experiment: it doesn’t always have to be in a meeting room, maybe go to the team area and do it there. If there are a number of teams, then stakeholders probably don’t have time to go to 5 Sprint Reviews, in these circumstances a marketplace works well. Think of each team as a different market stall, and the shoppers (stakeholders) go looking for the features that interest them, armed with a list of what each team delivered. Obviously the teams with the best refreshments generally get the biggest crowds.
The Sprint Review it about the Product, so the Product Owner is key here. They own the return on investment, so everybody should respect them as the final decision maker. However it is important that people feel heard, so make sure something is done with all feedback. Visibly add something to the Product Backlog, to make sure a conversation happens later or after taking the feedback, thank the stakeholder for it and say No for this business reason.
It should be the development team though that gets to demonstrate what they have delivered that Sprint. This is part of the celebration, but you also want them to feel the feedback when it hasn’t gone so well. It makes it feel more real when they then reflect during the Sprint Retrospective.
For the ScrumMaster it might seem more straightforward than Sprint Planning or the Sprint Retrospective. However you might find you need all of your ScrumMaster super powers to keep the conversations balanced and healthy. This is about feedback, but guard against anything getting personal or overly critical of the team, it isn’t going to help. Focus people on working with facts, whatever did happen in the last Sprint was the only thing that could have happened, given what was known. If something new has been discovered through the Sprint Review celebrate that as learning, but make sure something is done with that treasure you have uncovered.
If you found this useful, check out our other Scrum Events posts in our Scrum Fundamentals series.