There are plenty of failure possibilities with Scrum. Given that Scrum is a framework with a reasonable yet short “manual,” this effect should not surprise anyone. For example, what if your Scrum team repeatedly faces unengaged stakeholders at the Sprint Review? How can the Scrum team stay on track in accomplishing the Product Goal when a vital feedback loop is missing?

Join me and delve into how to support your stakeholders in living up to their part of the collaboration with the Scrum team in less than two minutes.

The Scrum Guide on the Sprint Review

According to the Scrum Guide, the Sprint Review serves the following purpose:

The purpose of the Sprint Review is to inspect the outcome of the Sprint and determine future adaptations. The Scrum Team presents the results of their work to key stakeholders and progress toward the Product Goal is discussed.

During the event, the Scrum Team and stakeholders review what was accomplished in the Sprint and what has changed in their environment. Based on this information, attendees collaborate on what to do next. The Product Backlog may also be adjusted to meet new opportunities. The Sprint Review is a working session and the Scrum Team should avoid limiting it to a presentation.

The Sprint Review is the second to last event of the Sprint and is timeboxed to a maximum of four hours for a one-month Sprint. For shorter Sprints, the event is usually shorter.

Source: Scrum Guide 2020.

The Sprint Review is Empiricism at work: inspect the Product Increment and adapt the Product Backlog. The Developers, the Product Owner, the Scrum Master, and the stakeholders need to figure out whether the Scrum team is still on track to accomplishing its Product Goal. It is the best moment to create or reaffirm the shared understanding among all participants whether the Product Backlog is still reflecting the best use of the Scrum team’s time, thus maximizing the value delivered to customers within the given constraints while contributing to the viability of the organization. (By the way, it is also because of this context that calling the Sprint Review a “demo” does not match its importance for the effectiveness of the Scrum team.)

The Sprint Review is thus an excellent opportunity to talk about the product's general progress, and the stakeholders' collaboration is essential to reap the gains from this Scrum event.

Reasons for Unengaged Stakeholders at the Sprint Review

In my experience, stakeholders may be unengaged at the Sprint Review for several reasons, for example:

• They do not understand the importance of the Sprint Review: Not everyone in the organization is familiar with agile product development practices and principles. (Maybe, your stakeholders do not understand the importance of the event. Nevertheless, they want to show up because they have been told the Sprint Review is essential.)
• Waste of time: Your stakeholders do not feel seen, heard, or respected. They are convinced that the Scrum team is ignoring their business needs. (This points to a failing relationship between stakeholders and the Product Owner or a flawed product discovery process.)
• No continuity: There is no continuity in the attendance of stakeholders. (Longevity is not just beneficial at the Scrum team level but also applies to stakeholder attendance. If they change too often, for example, because of a rotation scheme, their ability to provide in-depth feedback might be limited.)

The Consequences: As a result of this shortcoming in harnessing all learning opportunities, Scrum teams can quickly revert into feature factories focused on output, not an outcome, believing they still deliver value. Also, you will probably observe a diminishing level of trust between the stakeholders on the one side and the Scrum team on the other. Consequently, stakeholders might be tempted to exert more control over the development process by “tightening the leash,” for example, by demanding detailed reports to satisfy their information needs or setting arbitrary deadlines. Just to be safe, of course, you cannot trust these nerds, can you?

The Solution: If your stakeholders lack an understanding of agile product management in general and Scrum in particular, volunteer to teach them. For example, offer workshops on Scrum. Also helpful is embracing radical transparency regarding what the Scrum team does and over-communication in every aspect. Also, please include them in the product discovery and Product Backlog management processes. These need to be transparent systems supported by everyone on the stakeholder side.

If they are familiar with Scrum, make it worth their time: let the stakeholders drive the Sprint Review and put them at the helm, so you address their business needs. For example, make them feel heard and seen and give them a voice by organizing the Sprint Review as a science fair with several booths where team members introduce solutions to specific problems the Sprint addressed. Shift & Share is an excellent Liberating Structure microstructure for that purpose.

Unengaged Stakeholders at the Sprint Review — Conclusion

While the Scrum Guide is not honoring the crucial contribution of stakeholders for the Scrum team’s success formally, it does acknowledge their importance on numerous occasions. Interestingly, despite the severe consequences of stakeholders failing their Scrum teams, collaboration with stakeholders is often not a prime focus of Scrum Masters or Product Owners. However, Scrum is a team sport; for it to succeed, no one can be on the bench, stakeholders included.

Have you encountered Scrum teams with unengaged stakeholders? Please share your learnings with us in the comments.