Techniques for improving the Sprint review Scrum

chuzzeteAgile, Agile Coaching, Coaching teams from forming to performing, Forming-Telling, Inspiring, Scrum2 Comments

Techniques for improving the Sprint review in Scrum In my workbook, I have documented several techniques to 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 held at the end of the sprint. 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: team-role-responsibilities 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:What other techniques could be used to improve the Sprint review?
  • What’s “Done”
    1. How? The Development Team will review, item by item, within the Sprint Backlog to show the Product Owner which acceptance criteria is done (If it wasn’t done previously during the sprint).
  • From What’s “Done”
    1. 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 goes through everything that was done during the sprint, instead of the ‘pick and choose’ criteria, sometimes the sprint review could be impacted in different ways.
  • Quick Updates
    1. What’s that? All sprint backlog items considered not “Done” but whose progress is considerable enough that it’s worthy to be demonstrated by the Development Team during the sprint review; in order to get feedback from the Stakeholders.
    2. Why? I’ve noticed that by not allowing the development team to present items considered not “Done” that they considered ready to be demonstrated, I was diminishing the power of short development cycles and feedback loops. Also it was causing frustration in the development team up to a point that it was generating a negative impact.
    3. Some results after several try outs. By doing this we showed the team what it means to add visibility and to be transparent when practicing Scrum; in addition to encouraging them to explain and get things done before the end of the sprint.
  • What’s Next
    1. Ask the Product Owner 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.
  • Jesus’s Sprint Review Templates
    1. Use Jesus’s sprint review template to help you when making preparations for facilitating, holding and tracking the sprint review.
  • Repeat, repeat and repeat
  1. Keep using these techniques until the team starts to own 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.
Willing to get more techniques for transforming your teams into high-performing sustainable Agile teams? Here some options to help you out:
  1. Get a copy of one my books.
  2. Improve your skills by registering at one of my upcoming trainings.
  3. Share this post with a friend.
  4. Comment this post with the techniques you use to make your Agile teams sprint review amazing.
Thank you for reading and inspiring me to continue sharing. Jesus

2 Comments on “Techniques for improving the Sprint review Scrum”

  1. 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.


    1. 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


Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.