DEV Community

Cover image for What’s New In the 2020 Scrum Guide Update
Paul Isaris
Paul Isaris

Posted on • Updated on

What’s New In the 2020 Scrum Guide Update

Post photo by pexels

Originally published on paulisaris.com

Introduction

2020 Is (finally) coming to an end, but it wouldn't leave us with anything less than another surprise!

On November 18, 2020, Ken Schwaber and Jeff Sutherland published an update of the Scrum Guide.

According to the co-creators, the Scrum Guide 2020 aims at “bringing Scrum back to being a minimally sufficient framework by removing or softening prescriptive language”.

In this article, we will review what was added, what was removed, what has not, and what you need to take care of.

For an audio version of the 2020 Scrum Guide, check this link

You can also see a side-by-side comparison of the new Scrum Guide here.

Scrum poster

image taken from scrum.org

In a nutshell

Simpler language, more inclusion with the "Scrum team", Addition of "Why?" To Sprint Planning

The new Scrum guide adopted a simpler language and generally removed software-specific terminology.

The authors also reduced it's size, from 19 pages in 2017, to 14 pages.

No more "3 questions", no servant-leadership

The Scrum Guide is now less prescriptive, and more direct.

It eliminates many suggestions such as the Daily Scrum questions, removes the "at least one mandatory action item from the Retrospective becoming a part of the Sprint Backlog" part as well as the advice on why Sprint cancelations are rare events.

There is neither mention of the three questions during the Daily Scrum, nor of the term "servant leadership" of the Scrum Master.

No mention of "agile"

A very interesting fact though, is that there is not mention of the "agile" word!

Instead, there is an abvious shift towards getting Scrum to follow the "lean" principle.

Main motto not stated

Also, the obvious is no longer stated: Scrum is indeed not trivial to master.

In a bigger nutshell

Changes that are worth mentioning

Here are the bolder changes that are worth to review and reflect on:

1. No mention of the three questions during the Daily Scrum

OK, let's begin with the elephant in the room. No more 3 questions imposed in the Daily Scrum meeting!

Even in the 2017 versions, the three questions “What did I do yesterday that helped the Development Team meet the Sprint Goal?” and so on, were optional.

This means that the "Developers" (since there is no more a "Development Team"), can follow any structure they want, provided that it focuses on the plan for the day.

2. No more "Development Team"

That's right! The Development Team is no more. Long live the "Developers"!

This aims to eliminate the team within a team (often forming a silo) and normalize the often alienated relationship between the Product Owner and the Development Team.

Additionally, this change was to increase responsibility for the Product as one team and not just as the Product Owner.

Every member of the Scrum Team has the responsibility of the Product being built!

3. A brand new Sprint Planning

Since 2017, the focus on Sprint Planning was on "what we are building", and "how we are building it"
The Sprint Planning in 2020 has been enriched with a third topic - Why:

To make it easier for stakeholders to inspect a Product, the Scrum Team must now also focus on "Why" they are selecting the designated Backlog items, from the Product Backlog.

It's the job of the Product Owner to propose how this Sprint could increase the product’s value.

Read more here.

4. “Done” now creates a Product Increment

This change was made to embrace the quality of work.

According to the new guide:

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

5. Definition of Done Created By Scrum Team

Alright, so this is a big change.

From the 2020 Scrum Guide:

“The entire Scrum Team is accountable for creating a valuable, useful Increment every Sprint.”

While there are still explicit accountabilities for the Product Owner, Scrum Master, and Developers, all three roles must work together effectively to be successful with Scrum.

This is another evidence that Scrum now is following a more holistic approach.

A Definition of Done is most effective when created as a collaboration among the entire Scrum Team.

So, next time you are planning your Scrum and defining the Definition of Done, don't forget to also include the Product Owner and the Scrum Master in the process!

Read more here.

6. Don't present partially done items in the Sprint Review

That's right. we already knew that partially "Done" items were not accepted as part of the Increment.
But, this version of the guide goes a step further: Don't present them, and never speak about them until they are "Done".

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

7. A new term: The Product Goal

As the new guide states, there is a new kid around the block!

"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 of the Scrum Team."

Don't freak out, the Product Goal is not entirely new, since Scrum teams had a goal anyway. (What is the point of building software if you don't have a goal...?)

But it now has a name and it is clearly defined.

The Product Goal provides context to the Product Backlog.

It can be thought of as the "why" we are doing all of this work. It can be used as the elevator pitch to "what is the Scrum Team working on?".

So think of it more as a 1-sentence way of describing the whole product, and why you are building it!

8. Don't treat Sprint Review as a "Release Gate"

Many Scrum teams have shifted from constructive Sprint reviews to "Release Gates", making the Sprint Review just a meeting to tell the Product Owner "You can go ahead and release the increment now!".

The new Scrum guide addresses this by stating that

"The Sprint Review should never be considered a gate to releasing value."

So use the Sprint Review to learn and reflect, and detach it from the release cycle.

9. New Product Explanation

With a brand new Product Explanation, it becomes clear that Scrum now shifts beyond just software. In my opinion, it won't be long before we see Scrum implemented widely in non-software teams, as well.

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

10. Servant leadership no longer mentioned

Even if servant leadership is not mentioned directly, I don't think that the authors aim to shape Scrum Masters to be anything else than servant leaders.

The new guide describes the Scrum Master as following:

"Scrum Masters are true leaders who serve the Scrum Team and the larger organization."

It is now likely that the "Scrum Master" job title will include a job description that is larger than the accountabilities described in the Scrum Guide since it is treated as an organization leader role.

11. The spotlight is 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 is a more holistic approach than the previous version had. Now, it is clearly stated that it's not only developers who bear responsibility for the product, but the team as a whole!

12. "Commitments"

The Product Goal, the Sprint Goal, and the Definition of Done are now mentioned as "Commitments".

This is a bridge to connect Scrum Values (commitment, focus, respect, courage, openness) with the "Scrum Empiricism": Transparency, Inspection, and Adaptation.

The Scrum Guide describes a commitment as:

“Each artifact contains a commitment to ensure it provides information that enhances transparency and focus against which progress can be measured.”

Each of the three artifacts now contains "commitments" to them.

  1. Product Goal is the commitment for the Product Backlog.
  2. Sprint Goal is the commitment for Sprint Backlog.
  3. Definition of Done is the commitment to the Increment.

Read more here.

Scrum poster

image taken from scrum.org

Further Readings

  1. Scrum Guide 2020 and 2017: A Side-by-Side Comparison

  2. Scrum Guide 2020 Update - What has been removed

  3. Scrum Guide 2020 Update - Introducing the Product Goal

  4. Why, What, How - Sprint Planning

  5. What 4 Key Changes To The Scrum Guide Tell Us About Scrum

  6. 2020 Scrum Guide: Definition of Done Created By Scrum Team

  7. A Home for Product Goal, Definition of Done, and Sprint Goal

  8. Scrum Guide 2020 Update - Commitments

Conclusion

The 2020 Scrum Guide includes significant changes to the framework to broaden its appeal to applications beyond software development.

It simplifies the language used, and it empowers the "Scrum Team", in favor of the "Development Team".

It also makes the Sprint more meaningful, by making the Sprint Goal obligatory.
Scrum Master as a role is now treated as a leader of the organization, and not just a mere coach who acts upon request, as a servant leader.

In my opinion, the changes are in the right direction.

More responsibility to the team as a whole, and an apparent need for the Developers to start collaborating more with the Product Owner.

The Product Owner now has more responsibility for the Product Backlog, since they have to explain the current Product Goal to the whole Scrum Team.

But, don't fret. As stated on scrum.org website, Scrum is still Scrum!

What is your opinion on the Scrum Guide 2020 changes?

Latest comments (3)

Collapse
 
devdufutur profile image
Rudy Nappée

You did not mention the major breaking change (IMO) : the word agility totally disappeared ! And the word lean appeared in scrum theory paragraph !

Scrum is founded on empiricism and lean thinking. Empiricism asserts that knowledge comes from experience and making decisions based on what is observed. Lean thinking reduces waste and focuses on the essentials.

Scrum is no more promoting nor embracing agility

Collapse
 
pavlosisaris profile image
Paul Isaris

You are right, Rudi. I also think that Scrum is trying to shift away from agility, because people have misunderstood agility as "being open to do anything, at any cost". Lean promotes waste reduction and a focus on the bare bones. Let's see if Scrum will try to advocate this!

Collapse
 
devdufutur profile image
Rudy Nappée

I agree ! I think they wanted as well to take distance with frameworks like SAFe, which kind of misguided agility