Scrum: 14 Sprint Review Anti-Patterns
Scrum: 14 Sprint Review Anti-Patterns
Is your Scrum team's Sprint review unproductive or stuck in a rut? Read on to discover some common mistakes Scrum teams make in their Sprint planning and reviews.
Join the DZone community and get the full member experience.Join For Free
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 about Scrum’s core principle: inspect and adapt. The development team, the product owner, and the stakeholders need to figure out whether they are still on track to deliver 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. 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 soon as possible.
Sprint Review Anti-Patterns
Typically, you can observe the following Sprint review anti-patterns.
Sprint Review Anti-Patterns of 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”?)
- Delayed Sprint Acceptance: The product owner uses the Sprint review to accept user stories. This should be decoupled from the sprint review. The product owner should accept user stories the moment they are meeting the acceptance criteria.
- Unapproachable PO: The product owner is not accepting feedback from the stakeholders. Such a behavior violates the prime purpose of the Sprint review ceremony.
Sprint Review Anti-Patterns of 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 ceremony.
- Same Faces Again: It is always the same representatives from the development team who participate. Unless the organization works with several teams based on LeSS (Large Scale Scrum), this is not a good sign. The challenge is that you cannot enforce the team’s participation either, though. Instead, make it interesting enough that everyone wants to participate. Note: If the team does not attend each Sprint review religiously in full strength it is not an anti-pattern per se. However, there should be some rotation among participating team members.
- Side Gigs: The development team was working on issues outside the Sprint scope, and the product owner learns about those for the first time during the sprint review.
- Cheating: The development team demos items that are still buggy. There is a good reason to show unfinished work on some occasions. Buggy work, on the other hand, violates the DoD at an unacceptable level.
Sprint Review Anti-Patterns of the Scrum Team
- 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, getting feedback is the purpose of the exercise. A we-know-what-to-build attitude is bordering on hubris. 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. Tell a compelling story at the beginning of the review to engage the stakeholders. Leave out those user stories that are not relevant to the story. Do not bore stakeholders by including everything that was accomplished. We are not accountants.
Sprint Review Anti-Patterns of the Stakeholders
- Scrum à la Stage-Gate: The Sprint review is a kind of stage-gate approval process where stakeholders sign of features. This anti-pattern is typical for organizations that use an Agile-Waterfall hybrid. Otherwise, it is the prerogative or the product owner to decide what to ship and when.
- No Stakeholders: Stakeholders do not attend the Sprint review. There are several reasons why stakeholders do not go to the Sprint review: they do not see any value in the ceremony; it is conflicting with another important meeting; they do not understand the importance of the Sprint planning event. No sponsor is participating in the sprint planning, for example, from the C-level. From, my experience, you need to “sell” the ceremony within the organization.
- No Customers: External stakeholders—also known as customers—do not attend the Sprint review. Break out of your organization’s filter bubble, and invite some paying users of your product.
- Starting Over Again: There is no continuity in the attendance of stakeholders. Longevity is not just a team issue but also applies to stakeholders. If they change too often, for example, because of a rotation scheme, how can they provide in-depth feedback? If this pattern appears, the 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.
Conclusion: Scrum Sprint Review Anti-patterns
Scrum’s Sprint review is a simple yet meaningful ceremony. It answers the question whether the Scrum team is still on track to deliver value to the customers and the organization. Avoiding the Sprint review’s anti-patterns can significantly improve a team’s effectiveness.
Do you see any Sprint review anti-patterns that are missing? Please share with us in the comments.
Post Scriptum – Download the Anti-Patterns Guide:
Published at DZone with permission of Stefan Wolpers , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.