The fourth Scrum Event is the Sprint Review meeting. Review meetings are time-boxed and are meant to be a platform for the team to demonstrate working software to the stakeholders and receive feedback. From the official Scrum Guide:
A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed. During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint. Based on that and any changes to the Product Backlog during the Sprint, attendees collaborate on the next things that could be done to optimize value. This is an informal meeting, not a status meeting, and the presentation of the Increment is intended to elicit feedback and foster collaboration.
I reached out to our team to get their guidance on how to have a successful and valuable sprint review.
Jeff’s Top five things to do in a Sprint Review
Jeff’s Top five things NOT to do in a Sprint Review
There are three tips I would focus on to have a valuable sprint review meeting. One, to practice it beforehand. You don’t have to spend 8 hours crafting a flawless presentation, but running through what you’re going to show once or twice will ensure your review comes off professionally, and will help prevent you from getting too flustered if anything goes wrong. Two, don’t panic when someone disagrees with a decision you made – instead, defer. Acknowledge their question and make sure they’re heard, but offer to discuss it outside of the review in greater depth. And three, do your best to keep the meeting on track. Many stakeholders might not have as much insight into the day-to-day development that goes on and it’s very easy for a meeting to get off track as they see something unrelated that they want to discuss. This is still valuable feedback which should be recorded and discussed, but it can spiral out of control until the review has gone completely off track, defeating the original purpose of showing what you wanted to review with everyone.
Over the years a couple of things have really should out to me:
What makes a great Sprint Review? Making the Sprint Review a Working Session. Reminding yourselves (and your stakeholders) that the goal is to get feedback and make changes to the Product Backlog as needed. Using powerful questions to generate conversation if it isn’t happening naturally. What does that mean? It means using “Who” and “What” instead of asking binary questions. It means asking a specific person (you could even warn them first) how they might change the new feature you added. It also means turning away from Power Point and into demos (especially the hands on variety).