The Scrum Guide is Dead — Long Live the Scrum Guide!

Insight categories: AgileDevOpsProject ManagementTesting and QATechnology

Every few years, Scrum originators Ken Schwaber and Jeff Sutherland publish an updated version of their Scrum Guide, which completely defines the framework, including its roles, events, artifacts, and rules. It’s been a while since the last updates in Scrum Guide happened. And here it is!

The new version from November 2020 brings some really interesting changes. Personally, I welcome such amendments, which bring more flexibility into the process. But, let’s have a step-by-step overview according to

1 . Even Less Prescriptive

Over the years, the Scrum Guide started getting a bit more prescriptive. The 2020 version aimed to bring Scrum back to being a minimally sufficient framework by removing or softening prescriptive language (e.g., removed Daily Scrum questions, soften language around PBI attributes, soften language around retro items in Sprint Backlog, shortened Sprint cancellation section, and more).
What does it mean?

It is a current reality that there are as many Scrum implementations as products that use Scrum as a main SDLC approach. The above changes bring more flexibility to the framework. Why? Let’s take a look at it closely:

(a) We are not obliged to use Daily Scrum questions as a must-have. It is important that people hear each other, share opinions, and seek help if needed. There are many ways to build up a conversation in the team, and we should not limit ourselves with  the questions/statements, “What I did,” “What I will do,” and “What are impediments?”.

(b) If we are talking about Product Backlog Items (PBI), then it is always a good idea to have a sufficient level of details, size, value, etc. However, it is important that such items should correspond to business needs and domains. As a result, PBIs may contain the mentioned attributes, but they are not limited to them. Softening the PBI attributes is an extension to flexibility and avoiding the call to order.

(c) Retro items are now more abstract. Authors give us just a heads-up of what key aspects should be worked through during the retrospective meeting. Dozens of available tools allow us to pick the approach to retrospective that works best for our team. Overall, it leads to decreasing the prescription on who should do what and focusing more on the results.

(d) ScrShortening other parts in the guide gives more clarity and does not overload the process description with obvious consequences if some action like “Sprint Cancellation” takes place.

Scrum guide prescriptive

2. One Team, Focused On One Project

The goal was to eliminate the concept of a separate team within a team that has led to “proxy” or “us and them” behavior between the PO and Dev Team. There is now just one Scrum Team focused on the same objective, with three different sets of accountabilities: PO, SM, and Developers.
What does it mean?

The previous version recognized no sub-teams in the Development Team, and finally this approach has been moved to the level of the entire Scrum Team. The very first elimination of “us and them” behavior happened in 2011 by removing the reference to chickens and pigs concept. And now it is a logical continuation of eliminating the separation of PO and Dev Teams. The size of a team is now in reference to the whole Scrum Team and not to Developers only. In addition, the 2020 version of the guide recommends but is not limited to having up to 10 people in a Scrum Team, with a good explanation of why small teams work better. 

Such changes should bring more product and process ownership to the Scrum Team. The closer a Scrum Team works together, the better its cooperation to deliver really valuable products.

Scrum guide one team

3. Introduction of Product Goal

The 2020 Scrum Guide introduces the concept of a Product Goal to provide focus for the Scrum Team toward a larger valuable objective. Each Sprint should bring the product closer to the overall Product Goal.
What does it mean?

Perhaps the most important change is the introduction of the Product Goal into the overall concept of the framework. Nowadays, Scrum is being adopted by many domains beyond software product development (where it has its roots). A product can also be a service, a physical product, or something more abstract. Depending on the expected results, in many approaches, this could be considered as an intermediate result for those products that slice their value by milestones or releases.

The Product Goal describes a future state of the product, and it is very important to stick to the defined goal in order to constantly check if the Scrum Team produces valuable products. Without sprint-to-sprint aligning to Product Goal, the Scrum Team could turn to the wrong path and doom the product.

Scrum guide product goal

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

The previous Scrum Guides described the Sprint Goal and Definition of Done without really giving them an identity. They were not quite artifacts but were somewhat attached to artifacts. With the addition of the Product Goal, the 2020 version provides more clarity around this. Each of the three artifacts now contain “commitments’”to them. For the Product Backlog, it is the Product Goal; the Sprint Backlog has the Sprint Goal; and the Increment has the Definition of Done (now without the quotes). They exist to bring transparency and focus toward the progress of each artifact.
What does it mean?

Commitment is the willingness to work hard and give the energy and time to a job or an activity. The creation of an artifact must be dictated by the desire to achieve specific goals. And thanks to “commitments,” we can draw a single line from the Product Backlog Item to the desired state of our product. PBI becomes an increment once it meets the commitment “Definition of Done.” The set of increments aligned to the commitment “Sprint Goal” moves the product closer to the desired state, which is outlined in the “Product Goal” commitment.

Scrum guide definition

5. Self-Managing Over Self-Organizing

Previous Scrum Guides referred to Development Teams as self-organizing, choosing who and how to do work. With more of a focus on the Scrum Team, the 2020 version emphasizes a self-managing Scrum Team, choosing who, how, and what to work on.

What does it mean?

Involving the Product Owner and Developers into a single Scrum Team leverages the opportunity to flatten the SDLC by better incorporating what needs to be considered during upcoming development.

Scrum guide self organizing

6. Three Sprint Planning Topics

In addition to the Sprint Planning topics of “What” and “How,” the 2020 Scrum Guide places emphasis on a third topic, “Why,” referring to the Sprint Goal.
What does it mean?

The idea is quite simple. During the Sprint Planning, the Product Owner proposes how the product could increase its value in the current Sprint. The whole Scrum Team then collaborates to define a Sprint Goal that communicates why the Sprint is valuable to stakeholders. 

The order of Sprint Planning: Why -> What -> How

In fact, this is another opportunity to ensure that the current Sprint Goal is aimed to increase the value. Also, this type of planning connects the dots between the Sprint Goal and Product Goal.

Scrum guide three


The 2020 Scrum Guide provides overall simplification of the language for a wider audience. It has placed an emphasis on eliminating redundant and complex statements, as well as removing any remaining inference to IT work (e.g., testing, system, design, requirement, etc). The Scrum Guide is now less than 13 pages.

The newer version has less prescriptive language because, based on current realities and wide Scrum usage, the main elements of Scrum should be context-sensitive and dependent on particular products or conditions rather than work as a comprehensive solution that could not fit other products.


Scrum guide


Roman Shcherbak

Project Manager, Engineering — Scrum Master

View all Articles

Trending Insights

If You Build Products, You Should Be Using Digital Twins

If You Build Products, You Should Be Using...

Digital TransformationTesting and QAManufacturing and Industrial
Empowering Teams with Agile Product-Oriented Delivery, Step By Step

Empowering Teams with Agile Product-Oriented Delivery, Step By...

AgileProject ManagementAutomotiveCommunicationsConsumer and RetailMedia

Top Authors

Lavanya Mandavilli

Lavanya Mandavilli

Principal Technical Writer

Oleksandr Fedirko

Oleksandr Fedirko

Senior Solution Architect

Mark Norkin

Mark Norkin

Consultant, Engineering

Deborah Kennedy

Deborah Kennedy

Associate Vice President,Client Engagement

Randy Merry

Randy Merry

Chief Technology Officer, Medical Technology & Healthcare

All Categories

  • URL copied!