Techniques for improving the Sprint review Scrum

In Agile, Agile Coaching, Coaching teams from forming to performing, Forming-Telling, Inspiring, Scrum by chuzzete2 Comments

Techniques for improving the Sprint review in Scrum

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 your copy of my worbook “Forming Agile Teams” now.
  2. Register in my upcoming working “Coaching teams during iteration/sprint planning“.

Thank you for reading and inspiring me to continue sharing.

Jesus

Comments

  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.

    Cheers!

    1. Author

      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

      Jesus

Leave a Comment

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