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