TL; DR: 15 Sprint Review Anti-Patterns
Are we still on track to accomplish the Product Goal? Moreover, how did the previous Sprint contribute to our Scrum team’s mission? Answering these questions and adapting the Product Backlog in a collaborative effort of the Scrum Team with 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.
🇩🇪 Zur deutschsprachigen Version des Artikels: 15 Sprint Review Anti-Patterns.
🗞 Shall I notify you about articles like this one? Awesome! You can sign up here for the ‘Food for Agile Thought’ newsletter and join 35,000-plus subscribers.
🎓 Join Stefan in one of his upcoming Professional Scrum training classes!
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. 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 general progress of the product. The Sprint Review’s importance is also the reason to address Sprint Review anti-patterns as a Scrum team as soon as possible.
Sprint Review Anti-Patterns
Often, you can observe some of the following anti-patterns:
The Product Owner
- Selfish PO: Product Owners present “their” accomplishments to the stakeholders. (Scrum is a remarkably egalitarian affair: No one has any authority to tell teammates what, when, or how to do something. There are no sub-roles on Scrum teams, and there is no hierarchy. Instead, Scrum builds everything on self-management and collective responsibility—the Scrum team wins together, and the Scrum team loses together. Remember the old saying: There is no “I” in “team?”)
- “Acceptance” by the PO: The Product Owner uses the Sprint Review to “accept” Product Backlog items that Developers consider “done.” (A formal "acceptance" of work packages by the Product Owner is not foreseen in Scrum, for there is the Definition of Done. However, a feedback loop—did the Developers deliver the agreed-upon functionality?—is valuable. However, Product Owners should also decouple this feedback loop from the Sprint Review. Instead, Product Owners should communicate with the Developers whenever needed or when work items meet the Definition of Done.)
- Unapproachable PO: The Product Owner is not accepting feedback from stakeholders or the Developers. (I get it: Loving your solution over the customers’ problems feels good. Moreover, a bit of confirmation bias may prevent our Product Owners from getting distracted from pursuing their beloved solution. But unfortunately, they do not get paid to roll out their solution. This “living in their PO bubbles” approach hence violates the prime purpose of the Sprint Review event: Figure out collaboratively whether the Scrum team is still on track to meeting the Product Goal—which requires openness on the side of the Product Owners in the first place.)
Sprint Review of the Developers
- Death by PowerPoint: Participants of the Sprint Review 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. The Sprint Review is not a “demo,” carefully avoiding all obstacles to preserve the illusion of progress and control. Instead, it is an essential opportunity to inspect what the Scrum team accomplished, receive valuable feedback, and adapt the Product Backlog collectively. It is about creating transparency on the state of the progress toward the Product Goal.)
- Same faces again: It is always the same Developers who participate in the Sprint Review; however, they are not all Developers. (Unless the organization scales Scrum based on LeSS or Nexus and we are talking about the overall Sprint Review, this Sprint Review anti-pattern of limited attendance of Scrum team members is a bad sign. The Sprint Review needs all Scrum team members on deck to maximize the learning. The challenge is that you cannot enforce your teammates’ participation either. Instead, make it interesting enough that everyone wants to participate. If this is not happening, you should ask yourselves how you have contributed to this situation in the past. It is lucky a coincidence that an event tailored to this need follows immediately after the Sprint Review — the Retrospective.)
- Side gigs: The Developers worked on issues outside the Sprint Goal, and the Product Owner learned about those for the first time during the Sprint Review. (This Sprint Review anti-pattern is truly “rocking the boat.” Focus, commitment, and openness — just to name the most apparent Scrum values violated here — are the first principles for collaboration among Scrum team members. Anything that the Developers want to address during the Sprint needs to be communicated during the Sprint Planning. However, a particular case is when the Product Owner is usually so pushy about shipping new features that there is little or no time to attend to refactoring or bug fixing unless the Developers tackle these jobs under the radar. In this situation, I would have sympathy for the approach. Nevertheless, the Scrum team needs to fix this problem. Generally, allocating 20 % of the team’s capacity to the before-mentioned tasks could be a start.)
- Undone is the new “done:” More often than not, the Developers show work items that are not “done.” (There is a good reason to show unfinished work on some occasions. For example, to provide transparency to stakeholders on essential yet challenging tasks. However, regularly reporting to Sprint Review attendees on partially finished work violates the concept of “Done,” one of Scrum’s first principles. There is no need for a successful Scrum team to demonstrate to stakeholders that they are worth their pay-cheques.)
Sprint Review Anti-Patterns of the Scrum Team
- No Sprint Review: There is no Sprint Review, as the Developers did not meet the Sprint Goal. (A rookie mistake. Particularly in such a situation, a Sprint Review is necessary to create transparency with stakeholders and inspect the Increments that the Developers nevertheless managed to accomplish.)
- Following a plan: The Scrum Team does not use the Sprint Review to discuss the current state of progress toward the Product Goal 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. We do not want to recreate “watermelon” status reports regarding the Product Goal: green on the outside; however, deep red on the inside. Read More: Sprint Review, a Feedback Gathering Event: 17 Questions and 8 Techniques.)
- 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 Sprint review on the task the Scrum team ventured out to accomplish and engage the stakeholders with that narrative. Leave out those work items 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 far 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: there are some happy agile islands, for example, our Scrum team, surrounded by a sea of waterfall, driven by functional silos, budgeting, and top-down goal-setting. Still, in such a world, the Scrum team is tasked with accomplishing a Product Goal. Therefore, it is the prerogative of the Scrum Team to decide what to ship and 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. In addition, 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 at the beginning of using Scrum.)
- No customers present: External stakeholders—also known as customers—do not attend the Sprint Review. (Break out of your organization’s echo chamber and invite some customers and users to your Sprint Review. And do not let the sales folks object to this idea. Ignoring the direct feedback from customers at the Sprint Review inevitably leads to a lesser outcome.)
- Starting over again: 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. 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 where team members introduce solutions to specific problems the Sprint addressed. 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 whether the Scrum Team is still on track to deliver the best possible value to the customers and the organization as envisioned by the current Product Goal. Therefore, avoiding the before-mentioned Sprint Review anti-patterns can significantly improve a Scrum Team’s effectiveness in making your customers’ and users’ lives easier while contributing to a viable organization.
Are Sprint Review anti-patterns missing? Please share with us in the comments.
📖 Related Posts
A Sprint Review without Stakeholders — Making Your Scrum Work #3
Remote Agile (Part 7): Sprint Review with Distributed Teams
27 Product Backlog and Refinement Anti-Patterns
Scrum: 20 Sprint Planning Anti-Patterns
27 Sprint Anti-Patterns Holding Back Scrum Teams
Daily Scrum Anti-Patterns: 24+2 Ways to Improve as a Scrum Team
Download the Scrum Anti-Patterns Guide for free.
📺 The Sprint Review Anti-Patterns Video
The video of the webinar is available now:
Note: If the browser will not start the video automatically, click here to watch the replay of the webinar Sprint Review anti-patterns directly on Youtube.
✋ Do Not Miss Out and Learn more about Sprint Retrospective Anti-Patterns — Join the 11,000-plus Strong ‘Hands-on Agile’ Slack Community
I invite you to join the “Hands-on Agile” Slack Community and enjoy the benefits of a fast-growing, vibrant community of agile practitioners from around the world.
If you like to join all you have to do now is provide your credentials via this Google form, and I will sign you up. By the way, it’s free.
15 Sprint Review Anti-Patterns Holding Back Scrum Teams wurde zuerst auf Age-of-Product.com veröffentlicht.