Scrum Guide 2020: Beyond Software by Stefan Wolpers

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

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.)
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 2020