Things to consider if you are finding too many problems during your sprint reviews

Scrum’s sprint reviews are intended to surface issues that customers, users and stakeholders may have with the team’s work of the current sprint.

But sometimes, too many issues are identified. Not only can these be brutal for the team, Scrum Master, and product owner to sit through, having a lot of issues identified during the sprint review is a strong indicator that the team’s process could be improved.

Here are a few things to consider if you are finding too many problems during your sprint reviews.

  • Run shorter sprints. Finding a lot of problems in the review often indicates the team has gone astray in understanding users’ needs. They might find that shorter sprints give them more feedback opportunities.
  • Talk more often. One of the best ways to ensure team members are building what’s needed is for them to talk with users and customers more frequently. They don’t have to wait for sprint reviews to get a better understanding of what their users need.
  • Be sure you’re talking to the right people. Talking frequently won’t be helpful if team members are talking to the wrong users and customers. If you’re finding too many problems during the review, be sure the team is talking to the right people.
  • Demo early and often. Augment your conversations with users by giving them informal demos of what is being built as it’s being built.

In addition to trying one or more of these fixes, use the retrospective to discuss why so many issues were found during the review.

Finding problems isn’t necessarily a problem itself, but finding them as late as the sprint review is.

Addressing that and finding issues earlier will help your team succeed with agile,

Mike Cohn

Improving the Sprint Review with Liberating Structures

By using this format for the Sprint Review you’ll achieve its purpose: inspect the increment that was created during the Sprint as well as to adapt the Product Backlog based on new insights, ideas, and changes that result from this inspection. The Liberating Structures ensure it’s done in such a way that everyone is continuously involved & engaged. Shaping the next steps becomes a joint effort as well.

Read the complete article here:

Liberating Structures and (distributed) Scrum Events

For an upcoming meetup I’m preparing a session on how to use LS for Scrum Events and especially events where the participants are distributed and joining the event remotely.

Here’s a brief overview of some LS that can be used for the different Scrum events. I’ve marked all structures with an * that I’ve used myself in a distributed setting.

Refinement / Planning

Daily Scrum

Sprint Review

Sprint Retrospective

On the liberating Structures website you can find a design checklist for virtual meetings. Since the link is currently no longer working, you can find the document here:

Enhancing Sprint Review With The Speed Boat Game

The Speed Boat game explores user’s pains and jobs. The heart of the game is a metaphor of a Speed Boat (product). It has anchors: current problems and pains in using the Product that prevents it from moving forward. The stronger the anchor, the higher amount of customer pain, the more anchor slows the boat down.

Read all about it here:

Getting Results from Sprint Reviews

Some insights of this video include:

  • What could the agenda of a sprint review look like?
    • Show the (big picture) vision of the product
    • What was the sprint goal (vision of the previous sprint)
    • Discussing the sprint itself
      • what went wrong
      • what problems did we run into?
      • how did we solve these problems?
      • what still needs to be solved?
    • Review the increment (not really a demonstration, but an actual review)
    • Now that you’ve seen it, do we need to change anything?
    • Project likely completion dates
    • Collaborate/discuss what should be built next?
      • What is the marketplace we are operating in?
      • What are our competitors doing?
    • Final question: should we change the Product Backlog, should we change?

Sprint Review Anti Patterns and How to Overcome Them

If your Sprint Review looks like this, you are doing it wrong:

  • Approval Session
  • Development team presentation
  • Closed feedback bubble

Signs you are doing it right:

  • Product Owner owns the event
  • Who is who? Everybody is engaged.
  • It provides valuable feedback
  • It gives the direction where we want to move to
  • It can give insight in likely completion dates