14 Sprint Review Anti-Patterns Holding Back Scrum Teams

TL;DR: 14 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.

Scrum Anti-patterns Guide: 14 Sprint Review Anti-Patterns

The Purpose of Scrum’s Sprint Review

The sprint review is about Scrum’s core principle: inspect & adapt. 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. 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.

Update 2019-01-02: The Replay of the Webinar Sprint Review Anti-Patterns Is Available

The video of the webinar is available now:

Sprint Review Anti-Patterns (Hands-on Agile Webinar #9)

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.

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 side violates the DoD at an unacceptable level.)

Upcoming Scrum and Liberating Stuctures training classes and workshops — Berlin Product People GmbH

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 off 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 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 review event. No sponsor is participating in the sprint review, for example, from the C-level. To 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.)

Scrum Master Interview Question: free download of the most popular ebook on Scrum Master job interviews — by Age-of-Product

Conclusion: Scrum Sprint Review Anti-patterns

Scrum’s sprint review is a simple yet meaningful ceremony. It answers the question of whether the scrum team is still on track delivering value to the customers and the organization. Avoiding the sprint review’s anti-patterns can significantly improve a team’s effectiveness.

Are sprint review anti-patterns missing? Please share with us in the comments.

✋ Do Not Miss Out: Join the 3,100-plus Strong ‘Hands-on Agile’ Slack Team

I invite you to join the “Hands-on Agile” Slack team and enjoy the benefits of a fast-growing, vibrant community of agile practitioners from around the world.

Join the Hands-on Agile Slack Group

If you like to join now 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.

Related Posts

Scrum: 19 Sprint Planning Anti-Patterns.

28 Product Backlog and Refinement Anti-Patterns

4 thoughts on “14 Sprint Review Anti-Patterns Holding Back Scrum Teams”

  1. @devaux xavier
    SCM == Scrum Master??? It’s usually abbreviated SM. CSM is Certified SM and PSM is Professional SM, based on the certificate issuing group.
    Is referring to the Scrum framework as a”Method” (or process) a sign?
    An anti-pattern is a common (incorrect/inefficient/risky) practice (pattern) which is applied to a recurring or common problem. Therefore it is a sign that there is a deeper issue which needs to be addressed. It is an anti-pattern to use the Sprint Review as a stage gate indicating a knowledge gap in the purpose of the Scrum framework. Using and acting in terms of a project is an anti-pattern of the Scrum framework indicating a knowledge gap in its product-centric focus.
    Addressing opportunities to improve behaviors should be the focus.

  2. Question: Is that a “sprint review” if you only have it once at the end of the project? I doubt that this would classify as Scrum in the first place.

  3. One other sprint review common error : THE all-in one final sprint Review.
    It is a big “sprint review” done during the last sprint – the one before Production live, where the whole product is reviewed or checked…. pretty much the same way we have User Acceptance Tests at the end of a waterfall project

  4. Dear all,
    May be just question of wording.
    Personally, as a SCM, when I talk with anyone of the extended team ( Team = PO, SCM and dev team, extended team includes Stackholders, technical expert, architects, all people that can be involved occasionally during the project) I use “anti-patern” for key issues and I highlight “signs” of issues for concrete wrong behavior, wrong action and I try to correct the anti-patterns revealed by the signs rather than trying to correct the sign. I fully agree with that situations you described about are BAD one . No doubt about it. But I think most of them are signs, more than anti-paterns.
    Behing all the signs presented here, again according to me, I think there are the following key anti-patterns :
    – Wrong knowledge and application of the Method (so common anti-paterns)
    – Wrong PO mindset (an other so common anti-paterns)

    3 other signs (anti-patterns as you call them) I will add :
    – timing of the sprint review is not respected (often because the objective of the Sprint Review is not respected)
    – sprint review is just skipped !!! (Yes, It does happen !!!) Common bad reasons are : not useful, no time,
    – sprint review and retrospective are done in one common meeting

    Feel free to comment, personal progress comes from others comments and feedback

Leave a reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.