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

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

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.

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.

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.

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.

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.

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.

Conclusion

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.