Techniques for improving the Sprint review in Scrum
In my workbook Forming Agile Teams, I have documented several techniques to help ScrumMasters help Agile teams improve at the sprint review. Here is an introduction to what this ceremony is about, when it occurs, who participates and some techniques to master it.
What is the Sprint Review for?
It’s the event held to inspect what was done for the customer during the iteration and to adapt the Product Backlog if needed.
When is the Sprint Review held?
It’s recommended to be held at the end of the sprint. And remember, you and your team know more than anyone else about your context.
Who participates in the Sprint Review and how?
Here is what I’ve found that works better for each role when participating in the sprint review in Scrum:
What techniques could be used to improve the Sprint review?
I have developed the “Sprint review template ” as a way to help teams follow a structure that would guide them succeed during the first 8 to 10 sprint reviews. In the following paragraphs, I walk you through the steps I follow during what I call the Dry run meeting, to help the Scrum team get ready to shine at their sprint review:
Recurrent dry run meetings could be really helpful when getting ready for the sprint review. A dry run is a short meeting (for a two week sprint, it takes less than (1) hour) where the Scrum team meets to identify:
First, identify together what has been completed that is considered “Done” to complete the “Things to Demo” section.
How? The Development Team will go over the Sprint Backlog to validate with the Product Owner if we have met the Definition of Done (If it wasn’t done previously during the sprint).
Then, from What has been “Done”
Pick and choose the most important items to be demonstrated, based on what was defined in the Sprint goal. Why pick and choose? Depending on the audience, if the development team demonstrate every item that was done during the sprint, I have seen that customers/stakeholders lose interest and sometimes they stop coming to the meeting.
Pro-tipHelp the team become storytellers, using the following format for example:
Once upon a time, <Princess Lana> wanted to transform her kingdom into the most beautiful place of all. To do that she first asked us to repair the roof of her castle, so take a look at what we did with it (Demonstration time). Then she wanted us to paint it with a magnificent mosaic and given that we had only two weeks, we did it for on one of the four towers of the castle. What do you think about our work? (Feedback loop)
Then identify the Quick Updates section content.
Sprint backlog items considered not “Done” whose progress is considerable enough (more than 80%, I would recommend), so then is worthy to demonstrated them to get feedback from the Stakeholders an adapt the course of action if needed.
What’s the reason behind this suggestion? I’ve noticed that by not allowing the development team to demonstrate items not “Done”, but they considered ready to be demonstrated, I was diminishing the power of short development cycles and feedback loops. Also, I saw it caused frustration and disappointment to the development team, up to a point that it could generate a negative impact over results and team moral.
For that, I ask Product Owners to list everything that he/she considers will be part of the focus of the next sprint. It could be as simple as showing the next sprint goal and high level content to launch the conversation with the Stakeholders that would be present during the sprint review.
Finally, help your Product Owner complete the What’s Next section
What else could you do to help your team with improving their sprint reviews?
Repeat, repeat and repeat
Keep using these techniques until the team starts owning them. Something that I often do is not attending the dry-run meetings on purpose, so the team can figure it out on their own. The first time it could be awkward for the team, but after that they will be able to get it.
Where these techniques useful to you within your current context?
If so, here some options I offer you to continue your learning journey to help you help your team(s) improve their performance, connection and the way they deliver results to customers at the sprint review:
- Read my book “Forming Agile Teams” and get a deep dive into the techniques I have documented to help you grow as ScrumMaster/Team facilitator/Agile Coach/Agility Enabler.
- Subscribe to my monthly newsletter and get a grasp of the experiences I gather on the field, to help you thrive and survive at what you do as Agility Enabler.
- Improve your Agile Enabler skills, by registering at one of my upcoming trainings.
- Share this post with a friend.
- Comment this post and share the techniques you use to make your Agile teams sprint review the most amazing one
Thank you for reading and inspiring me to continue sharing.
I liked your post Jesús. Short and concise to the main goals and responsibilities. I liked your idea of dry run meetings.
I tried with some teams that during the review the stakeholders could test and manage the application by their own because:
1. This is a first-hand feedback for the team observing how stakeholders use the application.
2.It is a good test for the team because it is a must the design and user interaction are clear for stakeholders.
3.When stakeholders test their own the application, the feedback they give is richer.
Hi Israel, thank you for your answer. I’m happy that you like it, and you’re right about having the stakeholders trying apps by themselves and the feedback that it could get to the team. I’m curious about what other techniques you use to evaluate satisfaction regarding team’s performance. I would love to hear more about it !!
Cheers to you too