Engaging Sprint Review Meetings

The Scrum Guide™ says this about review meetings:

A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed.

Yes, we checked all the essential boxes for the sprint review:

  • invited key stakeholders
  • discussed the "Done" items
  • demoed the "Done" items
  • collaborated on the value of the product increment
  • discussed changes to the product backlog based on the review
  • made a foray into planning by looking at what's next based on the inspection results

But what happens if the sprint review still exhibits drag or a sense of ineffectiveness. Here are a few tips for great sprint reviews:

  1. Prepare, but keep it simple
    This is tricky. Preparation is everything, but teams tend to overly prepare things. The nature of the application plays a role. Web application testing has become so easy that any state can be induced automatically with ease. Other platforms have less tooling and might require more custom work to achieve quick scenario preparation. 2 hours of preparation might go into a 5 minute demo. 5 minute preparation might result in 2 hours of discussions with little effect involving a large audience so tailor this towards the people you need feedback from.
  2. Short and engaging
    Brevity and engagement are related. If you can make it easy to understand and short people will be much more likely to engage with you. And engagement from key stakeholders is one of the main goals in the review meeting. A short summary of the item that is going to be demoed is essential, viewing things from the stakeholders perspective helps.
  3. Practice
    Everyone who has spoken in public knows that practice is key. This does not mean that you have to excessively prepare it, but make it effortless.

    Bringing across your topics in a way that is inviting and having a presenter who is secure yields a calm and enjoyable atmosphere. Stakeholders enjoy being entertained.
  4. Value first
    Demoing a feature might be easy. Discussing the value of the feature is not. After seeing the increment, experiencing the changes first hand, the product owner and stakeholders reasses the value. We make it easier for them if we put value first. This means framing everything from the user perspective, talking about business impact and value created instead of features done. After all, value is primary indicator of success.

Of course the list is not complete, but I think it is worth experimenting with these things. I found them to be worthwhile improvements for reviews that tend to lose effectiveness over time.