Scrum Guide 2020 — The Development Team Is Dead; Long Live the Scrum Team!

TL; DR: The Scrum Guide 2020

The Scrum Guide 2020 is available now: Change is coming to make Scrum more accessible and inclusive beyond software development. Learn more about the changes, download the brand new and free Scrum Guide 2020 Reordered to spot patterns quickly, and join the Scrum community discussion.

Scrum Guide 2020 — The new edition of the Scrum Guide Reordered — Age-of-Product.com

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

How Scrum Changes with the New Guide

Scrum has witnessed many applications beyond its origins of software development over recent years. Being a real framework, Scrum has been augmented by many other practices, techniques, and tools, embracing many of those so tightly that they seem to be indistinguishable from the framework itself. Or, could you imagine running a Sprint without a Sprint board?

Consequently, the calls for accessibility and inclusion have become louder, and Ken and Jeff managed to answer them compellingly.

Cannot see the form?
Please click here.

My Top Changes Regarding the Scrum Guide 2020

I do believe that everyone interested in Scrum as a framework should take an hour and read the Scrum Guide 2020 or the Scrum Guide 2020 Reordered thoroughly. The call for accessibility and inclusion has been heard, and the proposed changes are plenty and far-reaching.

Foremost, the new Scrum Guide is less prescriptive, eliminating many suggestions such as the Daily Scrum questions, at least one mandatory action item from the Retrospective becoming a part of the Sprint Backlog or the advice on why Sprint cancelations are rare events. The Sprint Review lost its detailed recipe on how to run the event. Also, the obvious is no longer stated: Scrum is indeed not trivial to master.

Interestingly, the authors also axed other elements of the 2017 edition of the Scrum Guide that I thought less contested, for example, the magnitude of work allocated to Product Backlog refinement and servant-leadership.

Here are ten changes in the Scrum Guide 2020—in no particular order—I consider remarkable:

  1. No more roles: “The Scrum Team consists of one Scrum Master, one Product Owner, and Developers. Within a Scrum Team, there are no sub-teams or hierarchies. It is a cohesive unit of professionals focused on one objective at a time, the Product Goal.” (There are no more roles. However, there are now accountabilities.)
  2. There is no more Development Team: “Developers are the people in the Scrum Team that are committed to creating any aspect of a usable Increment each Sprint.” (I have supported many marketing and PR teams in exploring and using Scrum for their purposes. Not once have I encountered someone who could not understand the concept of the ‘development team member’ and apply it to their situation accordingly. Nevertheless, this simplification is welcome.)
  3. The focus on the Scrum Team: “The Scrum Team is responsible for all product-related activities from stakeholder collaboration, verification, maintenance, operation, experimentation, research and development, and anything else that might be required.” (This holistic approach was overdue; the Scrum team wins, the Scrum team loses—there are no factions within the Scrum Team but shared responsibility to create value for the customers. This strengthened team idea is also reflected in the point that the Scrum Team is now self-managing than (merely) “self-organizing.”)
  4. Servant leadership no longer mentioned: “Scrum Masters are true leaders who serve the Scrum Team and the larger organization.” (I have always considered servant leadership to be integral to Scrum’s success. This change probably positions the Scrum Master role closer to project managers and delivery managers.)
  5. The Product Goal: “The Product Goal describes a future state of the product which can serve as a target for the Scrum Team to plan against. […] The Product Goal is the long-term objective for the Scrum Team.” (I have never encountered a Scrum Team lacking an overarching goal, but probably that is a welcome clarification.)
  6. The Product explanation: “A product is a vehicle to deliver value. It has a clear boundary, known stakeholders, well-defined users or customers. A product could be a service, a physical product, or something more abstract.” (Scrum points beyond software; see above.)
  7. Sprint Reviews are no gates: “The Sprint Review should never be considered a gate to releasing value.” (This is another good pointer at the Scrum Team’s empowerment.)
  8. Increment releases are no longer a prerogative of the Product Owner: “The Sprint Review should never be considered a gate to releasing value. […] If a Product Backlog item does not meet the Definition of Done, it cannot be released or even presented at the Sprint Review.” (As the Scrum Guide 2020 states, the “Scrum Team is responsible for all product-related activities from stakeholder collaboration, verification, maintenance, operation, experimentation, research and development, and anything else that might be required.” This notion includes the decision of what to release when to whom.)
  9. Commitments: “Each artifact contains a commitment to ensure it provides information that enhances transparency and focus against which progress can be measured.” (There is now a home for the Sprint Goal, the Definition of Done—now without quotation marks—, and the previously mentioned Product Goal as all of them are linked to one of the three Scrum artifacts as commitments.)
  10. “Done” now creates a (potentially releasable) Product Increment: “The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product. The moment a Product Backlog item meets the Definition of Done, an Increment is born.” (Another welcome clarification: when work from the Sprint Backlog meets the Scrum Team’s quality standard, it constitutes a releasable Increment.)

As mentioned earlier, there are numerous additional tweaks here and there. To mention a few: The Product Backlog items are no longer estimated but sized, the Scrum Master is no longer removing impediments, but is now “causing the removal of impediments.” Moreover, the “Why is this Sprint valuable?” question has become a part of the Sprint Planning.

Conclusion—The Scrum Guide Edition 2020

The Scrum Guide 2020 includes significant changes to the framework to broaden its appeal to applications beyond software development. In my opinion, the Scrum Guide 2020 is a bold step in the right direction.

What is your opinion on the Scrum Guide 2020? Please share your thoughts with us in the comments.

✋ Do Not Miss Out: Join the 8,500-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.

Scrum Guide 2020 — Related Sources

The Scrum Guide 2020.

Download the Scrum Guide 2020 Reordered for Free.

Download the Scrum Anti-Patterns Guide: 160-plus ways to improve your way of Scrum.

6 thoughts on “Scrum Guide 2020 — The Development Team Is Dead; Long Live the Scrum Team!”

  1. Based on my experience, I have a couple of concerns regarding some of the changes to the Scrum Guide 2020.
    1.The Scrum Team: ” The entire Scrum Team is accountable for creating a valuable, useful Increment every Sprint.” [Scrum Guide 2020-page 5]
    The way I am reading this is that now, the Scrum Master is also accountable for the delivery. Doesn’t this mean that the Scrum Master has to be more involved in the delivery activities, bringing him/her closer to a Project Manager role?
    2. The Scrum Master serves the Scrum Team by “causing the removal impediments to the Scrum team’s progress” [Scrum Guide 2020 – page 6] vs removing impediments to the DT’s progress [Scrum Guide 2017 page 8]. How should I interpret this?
    3. Sprint Review: “The Product Backlog may also be adjusted to meet new opportunities” [Scrum Guide 2020-page 9] vs “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.” [Scrum Guide 2017 – page 13]. Does this mean the the Product Backlog is not necessarily an output of the Sprint Review any longer?
    4. Sprint Retrospective: “The Scrum team identifies the most helpful changes to improve its effectiveness. The most impactful improvements are addressed as soon as possible. They may even be added to the Sprint Backlog for the next Sprint”.[Scrum Guide 2020-page 10] vs Sprint Backlog: “To ensure continuous improvement, the Sprint Backlog includes at least one high priority process improvement identified in the previous Retrospective meeting.” [Scrum Guide 2017 – page 16]. Is this a departure from focusing on continuous improvement. learning organization towards delivery? (project management???]
    All my concerns stem from the fact that an agile organization should work differently than a traditional organization, should be focused on producing value, respecting the Scrum Values and the 3 Pillar of Scrum, empirical planning, continuous improvement and learning, measuring outcomes and not outputs, basically a different culture. To support all these, even organizational structure changes were required. All of these ensured that the organizations will be able to become flexible and adapt to changes in the market trend fast as well as improving the employees’ working environment. Yet, some of the changes in the Scrum Guide 2020, lead me to believe that we are going backwards and shift the focus to delivery while everything else takes a 2nd place. Could I please ask you to clarify or comment on my concerns?

  2. The self-organizing characteristics is now replaced by self-managed and this can create a confusion. General understanding is self managed team goes beyond self organizing team i.e. it decides What it needs to do in addition to How the work needs to be done. However during launch event Jeff explained that the goal takes care of of what and thus scrum team should be self managed.

  3. Every Increment is potentially releasable. Since the Product Owner is responsible for maximizing the value of the product, he or she may decide if an Increment should be released.

    On the other hand every Increment is a step towards the Product Goal and thus delivers value. Unless there are some kind of market or business changes, it should be released automatically.

  4. Interesting changes. Since the Scrum Team as a whole is now responsible for delivering value, does the Product Owner still have the last word on what should be released?

  5. Thanks, Stefan! I appreciate your analysis and of course the fact that the Scrum Guide is taking one more step beyond software development.
    I agree, the role „developer“ is often not understood outside the software world. So use „creator“ instead as a synonym – they are the people who create the increments.

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.