15 Sprint Review Anti-Patterns Holding Back Scrum Teams

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.

15 Sprint Review Anti-Patterns Holding Back Scrum Teams — Age-of-Product.com

Update 2019-11-10: I re-edited text, added new graphics as well as an excerpt from the Scrum Guide to clarify the purpose of the Sprint Review.

Do you want to get this article in your inbox? You can sign up here and join 24k other subscribers.

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.

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

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.)
    Sprint Review Anti-Patterns —Death by Slide Deck — Age-of-Product.com
  • 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.)

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

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. 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 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.)
    Sprint Review Anti-Patterns — Stage-Gate® — Age-of-Product.com
  • 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.)

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 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 with us in the comments.

✋ Do Not Miss Out: Join the 6,250-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

7 thoughts on “15 Sprint Review Anti-Patterns Holding Back Scrum Teams”

  1. As I got a certified scrum master recently and your blog helps me. As companies are shifting towards Scrum Framework removing the traditional method of executing the project. Thanks for your valuable info which useful for all scrum masters.

  2. I noticed there weren’t any anti-patterns addressing the Scrum Master. I think one may be the not present Scrum Master. They are there but not really doing anything to move the Sprint Review along. All responsibility has been handed over to the Product Owner.
    I am curious to see if anyone else has identified Scrum Master anti-patterns.

  3. @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.

  4. 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.

  5. 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

  6. 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.