Treating Sprint Reviews like Demos
Here is another common scenario we see frequently: On the last day of the sprint, stakeholders meet with the Scrum team. The development team demos what they’ve accomplished since the last sprint review. The stakeholders inspect the new functionality and the product owner collects their feedback. After the review, the PO adapts the product backlog based on this feedback. Nobody—not stakeholders nor members of the Scrum team—has a clear understanding of the direction of the project. The stakeholders simply saw a demo but weren’t given any context about how the team arrived at that increment.
In this scenario, the Scrum team was trying to do the right thing by meeting with stakeholders and allowing them to inspect the current increment, but they didn’t present their progress in a way that was truly useful to the stakeholders. Stakeholders should know the reasoning behind the sprint goal that the team accomplished as well as the direction the project is headed. Increment inspection should involve more than just demoing the functionality that the team has built since the last sprint review.
In order for the Scrum team to receive valuable feedback that can help them adapt the product backlog in an informed way and ensure that everyone (stakeholders and team members) truly understands the direction of the project, the team needs to create more transparency in sprint reviews. For example, here’s an agenda that can help make the sprint review a truly collaborative session:
- Explanation of the product owner’s vision for the product
- Review of the release plan and budget
- Description of the sprint goal for this sprint
- Review of the work and the product increment that the team built
- Assessment of current customer analytics and data
- Discussion of impediments the team is currently facing
- Collaboration with stakeholders to refine the product backlog
- Summary of where we’re going next and what we discovered in this event
With this agenda, the whole Scrum team needs to be prepared to present during the meeting, so they can provide a holistic view of what has happened since the last sprint review and what might happen in the future. It’s important that this event is viewed by both the Scrum team and stakeholders as a collaborative working session. The Scrum team must explain where they are, how they got there, what stands in their way, and where they’re going. Simply giving a demo to stakeholders misses an opportunity to discuss broader topics around the project, and doesn’t provide the product owner with fully informed stakeholder feedback for adapting the product backlog.
If your sprint reviews have become nothing more than demos, talk to your dev team and product owner about how you can make the event more collaborative (including using something similar to the sample agenda we provided). Doing so will make it a more worthwhile event for everyone involved, as shown in the figure.
The Scrum Guide doesn’t answer this question, but there are many ways that teams can prepare for a sprint review. Ideally, the sprint review agenda emerges throughout the sprint. Your team may decide to have a short meeting prior to the sprint review to dot the i’s and cross the t’s. The product owner may want to massage the agenda, since they know the stakeholders well. And you, the Scrum master, can suggest new ways to facilitate the event so it’s as collaborative as possible. However your team decides to craft the agenda, it’s important that you do some preparation to make the event organized and productive.