The Stagnant Sprint Review
In this anti-pattern, stakeholders arrive at the sprint review with a clear expectation of what will occur, as the agenda has been the same for several sprints. Some stakeholders check email or work on their laptops until the team discusses something that’s interesting to them, others funnel into the room late based on when they think the team will discuss information pertinent to them, and still others stop attending altogether. The stakeholders call the event “boring.” None of the stakeholders seem to express their opinions unless something extraordinary piques their interest. The stakeholders and Scrum team feel that the project is no longer very risky since the project has been in-flight for several sprints. But that belief of less risk could very well be an illusion.
So how do you avoid this situation? First and foremost, the sprint review agenda should change to reflect the Scrum team’s current circumstances, which shift frequently. (Stakeholders may change, too.) Varying the sprint review agenda is better than keeping it the same. A product owner should facilitate the sprint review in an engaging, collaborative way that involves everyone in attendance.
As Scrum master, you must work with your product owner and teach them how to lead the discussion to get the most out of the sprint review. If stakeholders are bored or uninterested, their lack of engagement will lead to missed opinions or ideas. The project can then be at risk because the team hasn’t received the feedback it needs to make decisions. Customers may find issues with the product in production, and they may discover that the product is missing important features. Collaborative sprint reviews mean that the Scrum team gets ideas and suggestions from stakeholders so that the team can change the direction of the product, and stakeholders are able to raise any issues early on.
Frequently change the format of the sprint review to keep everyone on their toes. Try different kinds of facilitation techniques, such as ones that involve visualization or Liberating Structures.[17] Keep an eye out for participants who are quiet and get them involved in a nonintrusive, collaborative way. Do your best to solicit opinions from everyone in attendance so that no one’s thoughts go unheard. Experiment with facilitation techniques and agendas to keep team members and stakeholders engaged in every sprint review.
We often see Scrum teams leaving a sprint review without any notes about what happened during the event. The product owner is accountable for updating and adapting the product backlog, but that’s not to say that the product owner is the only person who should take notes. In fact, everyone should take notes in a sprint review. Some of the best Scrum teams we’ve worked with sit and compare notes soon after the sprint review. This may occur ad hoc, in sprint planning, or right after the review, before the retrospective. After gathering everyone’s perspective, the product owner can then adapt the product backlog accordingly.