Scrum Guide 2020: A Major Upgrade For an Ever Fast-Paced Changing World

Image for post
Image for post

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

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.

Self-managing Teams

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.

Scrum Artifacts

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.

Product Goal

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

Scrum Events

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.

Sprint Planning

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.

Daily Scrum

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.

Retrospective

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! :)

The Startup

Medium's largest active publication, followed by +754K people. Follow to join our community.

Marc Rodriguez Sanz

Written by

Agile Coach and Practitioner | Growing healthy teams by putting people in the center of interactions | Working fully remote since October 2018.

The Startup

Medium's largest active publication, followed by +754K people. Follow to join our community.

Marc Rodriguez Sanz

Written by

Agile Coach and Practitioner | Growing healthy teams by putting people in the center of interactions | Working fully remote since October 2018.

The Startup

Medium's largest active publication, followed by +754K people. Follow to join our community.

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store