Scrum Guide 2020: A Major Upgrade For an Ever Fast-Paced Changing World
The Scrum Guide is the evolving document that determines the rules of the game of the Scrum framework, together with its pillars and values. Since its first publishing in 2010 as such, this body of knowledge has seen five updates. The last one was performed already three years ago, in November 2017.
This time, Jeff Sutherland and Ken Schwaber, its authors, have surprised us with a major upgrade that will allow Scrum practitioners to face the next years of the new decade with a renewed and fresher framework. For the first time since 2010, the extension of the guide has been reduced, from 19 pages to merely 13. And at the same time, new elements have been added to the framework.
As the authors mentioned during the official presentation of the new guide, “Scrum hasn’t changed, its description is just better”.
I invite you to continue reading to learn more about these changes. I will start with an overall summary of the changes in the guide spirit. Later, I will dig deeper into the specific changes at a team, artifact and events level.
The first thing you will realise when you grab and read the new Scrum Guide is that it is much more lighter, sharper and more straight to the point. This is also visible when you browse through the document, as the length of the sections has been substantially reduced, making Scrum a minimally sufficient framework and (even) less prescriptive than it used to be.
One of the items I find more interesting is the addition in the Scrum Theory section of a reference to Lean thinking and its continuous search for the reduction of waste. Something that most practitioners already were having in mind for long, and that has finally been incorporated into the Scrum Guide.
Another change is the fact that every Scrum artifact is now formally linked to a ‘Commitment’. Two of these commitments were already present in the previous version of the Scrum Guide, and a third one has been incorporated: the Product Goal. The purpose of these commitments is to provide transparency and focus toward the progress of the three artifacts.
And because Scrum is currently being used by all kind of teams, and aiming to make it open to a wider audience beyond the software development world, references to IT activities (testing, system, requirement, etc) have been purposefully removed.
The Basis of Scrum
The first sections of the Scrum Guide have been reformulated. The “Uses of Scrum” section has been removed and part of its contents have been moved to the section “Purpose of the Scrum Guide”, which now works as a preamble of the body of knowledge.
The “Scrum Definition” has been improved and streamlined, with a 4-step summary that allows everyone to grasp its iterative approach:
In a nutshell, Scrum requires a Scrum Master to foster an environment where:
1. A Product Owner orders the work for a complex problem into a Product Backlog.
2. The Scrum Team turns a selection of the work into an Increment of value during a Sprint.
3. The Scrum Team and its stakeholders inspect the results and adjust for the next Sprint.
Here, the guide also claims for the first time that “the Scrum framework is purposefully incomplete”, encouraging people and teams using it to use their collective intelligence to cover the parts not defined in the guide.
The “Scrum Theory” section has also been revised. As mentioned in the introduction, Lean thinking (focusing on simplicity and waste reduction) has been added to the foundations of Scrum, together with empiricism. Each of the three pillars of empiricism now contains a powerful, one-line sentence that summarizes their importance:
Transparency enables inspection. Inspection without transparency is misleading and wasteful.
Inspection enables adaptation. Inspection without adaptation is considered pointless. Scrum events are designed to provoke change.
Adaptation becomes more difficult when the people involved are not empowered or self-managing.
And in this last sentence of the previous quote we find yet another of the main changes of the Scrum Guide. Previously, the guided encourage Development Teams to be “self-organizing” teams, empowering them to choose who and how to do the work. In this new version, the focus moves up to the whole Scrum Team, which is encouraged to be “self-managing”, allowing them to internally decide “who does what and how”
Scrum Team and its Accountabilities
One of the goals of this new version of the Scrum Guide is to eliminate the idea of having more than one team, or a sub-team (the Development Team) within the Scrum Team, and this way avoid having potential misunderstandings and “us and them” behaviours, mostly between the Product Owner and Development Team.
The members of the Development Team are now called “Developers”, which together with the Scrum Master and the Product Owner, define the three “Accountabilities” within a Scrum Team. It is all worth mentioning that all references to the concept of “role” have been removed from the guide.
The new Scrum Guide also winks at scaling approaches when recommending to reorganize teams larger than 10 people into “multiple cohesive Scrum Teams, each focused on the same product”, with the “same Product Goal, Product Backlog and Product Owner”.
The sections referring to the Product Owner and the Scrum Master have also been shortened, while keeping the same spirit than before.
Artifacts are perhaps the section that have suffered a major improvement in this new version of the Scrum Guide, with a newly incorporated element: the Product Goal.
The three existing artifacts remain unmodified and now they all contain a commitment:
For the Product Backlog it is the Product Goal.
For the Sprint Backlog it is the Sprint Goal.
For the Increment it is the Definition of Done.
The purpose of these commitments is to reinforce empiricism and the Scrum values for both the Scrum Team and their stakeholders. Additionally, they ensure that each of the artifacts they are linked to provides enough information to enhance transparency and focus toward the progress of each artifact.
The Sprint Goal and the Definition of Done, that before were being mentioned in isolation throughout different parts of the Scrum Guide, have now found their place, next to the Sprint Backlog and the Increment.
As mentioned before, we can consider the Product Goal to be the biggest change in this new Scrum Guide.
The purpose of this commitment is to frame the work of the team in a longer time perspective than the Sprint, and allow them to have a direct connection to the outcomes and the customer value. Every Sprint should allow the product to be closer to the overall Product Goal.
In the previous version there was a reference to the vision of the product — this has disappeared.
As described in the guide:
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 in the Product Backlog. The rest of the Product Backlog emerges to define “what” will fulfill the Product Goal.
Additionally, the guide also contains a definition of what a Product is, clearly distinguishing it from the idea of ‘Project’.
Same as the other elements of Scrum, the Events have also been revised and improved. In general, the definition of each of these events, that in most of the cases had an extension of around one page, has been significantly reduced, in some cases, to barely 3 to 5 paragraphs.
The events that changed most are the Sprint Planning, the Daily Scrum and the Retrospective.
The Sprint Planning now consists of three different phases, each of them addressing a different topic.
A new topic “Why is this Sprint valuable?”, referring to the Sprint Goal, has been added before the already existing ones: “What can be Done in this Sprint?” and “How will the chosen work get done?”. These latter two remain unchanged.
The Daily Scrum has also been made less prescriptive, giving more freedom to the Developers to find their best approach to meet the purpose of the event. In this sense, the three traditional questions usually answered by the participants in this event have disappeared.
The Retrospective has not suffered many modifications. The main change here is that the language used to determine what to do with the action items identified as the outcome of the exercise has been softened. Now it reads: “the most impactful improvements (…) may even be added to the Sprint Backlog for the next Sprint”
What are your thoughts on this updated version of the Scrum Guide? I invite you to leave a comment! :)