15 Sprint Review Anti-Patterns
Stefan Wolpers — November 16, 2019 TL; DR: 15 Sprint Review Anti-Patterns
Are we still on the right track? Answering this question in a collaborative effort of the Scrum Team as well as internal (and external) stakeholders is the purpose of the Sprint Review. Given its importance, it is worthwhile to tackle the most common Sprint Review anti-patterns.
The Purpose of Scrum’s Sprint Review
The Sprint Review is Empiricism at work: inspect the Product Increment and adapt the Product Backlog. The Development Team, the Product Owner, and the stakeholders need to figure out whether they are still on track delivering value to customers. 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 resources, thus maximizing the value delivered to customers. It is also because of this context that calling the Sprint Review a “sprint 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 general progress of the product. The Sprint Review’s importance is also the reason to address Sprint Review anti-patterns as a Scrum Master as soon as possible.
What Does the Scrum Guide Say about the Sprint Review?
In contrast to other Scrum events, the Scrum Guide goes into detail regarding the Sprint Review. The Sprint Review includes the following elements (quote):
- Attendees include the Scrum Team and key stakeholders invited by the Product Owner;
- The Product Owner explains what Product Backlog items have been “Done” and what has not been “Done;”
- The Development Team discusses what went well during the Sprint, what problems it ran into, and how those problems were solved;
- The Development Team demonstrates the work that it has “Done” and answers questions about the Increment;
- The Product Owner discusses the Product Backlog as it stands. He or she projects likely target and delivery dates based on progress to date (if needed);
- The entire group collaborates on what to do next, so that the Sprint Review provides valuable input to subsequent Sprint Planning;
- Review of how the marketplace or potential use of the product might have changed what is the most valuable thing to do next; and,
- Review of the timeline, budget, potential capabilities, and marketplace for the next anticipated releases of functionality or capability of the product.
“The result of the Sprint Review is a revised Product Backlog that defines the probable Product Backlog items for the next Sprint. The Product Backlog may also be adjusted overall to meet new opportunities.”
Source: Scrum Guide 2017.
Sprint Review Anti-Patterns
Often, you can observe some of the following Sprint Review anti-patterns.
The Product Owner
- Selfish PO: The Product Owner presents “his or her” accomplishments to the stakeholders. (Remember the old saying: There is no “I” in “team?”)
- “Acceptance” by the PO: The Product Owner uses the Sprint Review to “accept” tasks/Product Backlog items. (An alignment — did the Development Team deliver the required functionality? — is useful and should be decoupled from the Sprint Review. The Product Owner should communicate with the Development Team when issues meet acceptance criteria.)
- Unapproachable PO: The Product Owner is not accepting feedback from stakeholders or the Development Team. (Such behavior violates the prime purpose of the Sprint Review event.)
The Development Team
- Death by PowerPoint: Participants are bored to death by PowerPoint. (The foundation of a successful Sprint Review is “show, don’t tell,” or even better: let the stakeholders drive the discovery.)
- Same faces again: It is always the same folks from the Development Team who participate, not everyone. (Unless the organization scales Scrum based on LeSS or Nexus and we are talking about the overall Sprint Review, this Sprint Review Anti-pattern is a bad sign. To maximize the learning, the Sprint Review needs all Scrum Team members on deck. The challenge is that you cannot enforce the team’s participation either, however. Instead, make it interesting enough that everyone wants to participate. If this is not happening, you should — as a Scrum Master — ask yourself how you have contributed to this situation.)
- Side gigs: The Development Team was working on issues outside the Sprint Goal, and the Product Owner learns about those for the first time during the Sprint Review.
- Cheating: The Development Team shows items that are not “done.” (There is a good reason to show unfinished work on some occasions. Partially finished work, however, violates the concept of “Done,” one of Scrum’s first principles.)
Sprint Review Anti-Patterns of the Scrum Team
- No Sprint Review: There is no Sprint Review, as the Development Team did not meet the Sprint Goal. (A rookie mistake. Particularly in such a situation, a Sprint Review is necessary to create transparency.)
- Following a plan: The Scrum Team does not use the Sprint Review to discuss the current state of the product or project with the stakeholders. (Again, creating transparency and receiving feedback is the purpose of the exercise. A we-know-what-to-build attitude is bordering on hubris.
- Sprint accounting: Every task accomplished is demoed, and stakeholders do not take it enthusiastically. (My suggestion: Tell a compelling story at the beginning of the review to engage the stakeholders. Leave out those user stories that are probably not relevant to the story. Do not bore stakeholders by including everything that was accomplished. We are not accountants; the output is less relevant by comparison to the outcome.)
The Stakeholders
- Scrum à la stage-gate®: The Sprint Review is a kind of stage-gate® approval process where stakeholders sign off features. (This Sprint Review anti-pattern is typical for organizations that use an “agile”-waterfall hybrid. However, it is the prerogative of the Product Owner to decide what to ship when.)
- No stakeholders: Stakeholders do not attend the Sprint Review. (There are several reasons why stakeholders do not participate in the Sprint Review: they do not see any value in the event, or it is conflicting with another important meeting. They do not understand the importance of the Sprint Review event. No sponsor is participating in the Sprint Review, for example, from the C-level. To my experience, you need to “sell” the event within the organization, at least in the beginning of using Scrum.)
- No customers: External stakeholders—also known as customers—do not attend the Sprint Review. (Break out of your organization’s echo chamber, and invite some paying users to your Sprint Review.)
- Starting over again: There is no continuity in the attendance of stakeholders. (Longevity is not just beneficial at the 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. If this pattern appears, the Scrum Team needs to improve how stakeholders understand the Sprint Review.)
- Passive stakeholders: The stakeholders are passive and unengaged. (That is simple to fix. Let the stakeholders drive the Sprint Review and put them at the helm. Or organize the Sprint Review as a science fair with several booths. Shift & Share is an excellent Liberating Structure microstructure for that purpose.)
Conclusion: Scrum Sprint Review Anti-patterns
Scrum’s Sprint Review is a critical Scrum event. It answers the question of whether the Scrum Team is still on track delivering the best possible value to the customers and the organization. Avoiding the before-mentioned Sprint Review’s anti-patterns can hence significantly improve a Scrum Team’s effectiveness.
Are Sprint Review anti-patterns missing? Please share it with us in the comments.
Business & Finance Articles on Business 2 Community
(80)
