Scrum Guide 2020 – What Changed and How will it Affect Scrum Classes?

See the latest changes to the Scrum Guide from Nov 2020 (PDF)

Summary: changes were moderate in the 2020 revision – very few will impact how people implement and practice Scrum day to day.  CSM class will need to continue to use some 2017 language and concepts until the exam changes (probably sometime in 2021 but no target date as of now).

From the Scrum Guide history – what changed (my view on class impact added in BOLD)

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.  Impact: some of what was “required” now becomes a pattern or “good practice” to consider.  Not sorry to see the “3 questions” go!  They were already optional in 2017.
2. One Team, Focused on One Product
   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.   Impact: this affects language in a lot of places and affects test questions.  Since the CSM Exam is still based on 2017, we’ll stick with the current language for now but make it clear what’s shifting here.
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.  Impact: new but a contained impact.  We already cover the concept of a Vision – this would be a step toward the vision, and we’ll discuss that.
4. A Home for Sprint Goal, Definition of Done, and Product Goal
   Previous Scrum Guides described 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 Product Goal, the 2020 version provides more clarity around this. Each of the three artifacts now contains ‘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.  Impact: except for the Product Goal, this is all repackaging of items we had before.  This clarifies that the Sprint Goal is a commitment but that was implied already.
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.  Impact: this is a broad change but subtle in its impact day to day.  A PO could already delegate some of the “what” to the developers – now it’s explicit that the Scrum team decides how to handle this.
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.  Impact: this is a real addition but is mostly just expanding on the existing idea of a Sprint Goal.
7. Overall Simplification of Language for a Wider Audience
   The 2020 Scrum Guide 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.  Impact: this is mostly a good thing – a few specifics covered below.

More details on what’s changed and why

There’s a big shift toward “one Scrum team” and reduced emphasis on different roles – this was particularly intended to avoid any idea of conflict between PO and “dev team”.   I like that the “self-managing” team now gets to decide how they divide up things like the “what”.  There are still some accountabilities that are called out specifically but mostly, things are left up to the team.

The word “roles” is gone and is replaced with “accountabilities.” Development Team as a “team” is gone and is replaced with simply Developers (which still does not mean coders – it means anyone involved in development of the product).   In the notes and blogs about the 2020 guide, it was clarified that “roles” are not incorrect, they just think the word “accountabilities” is more helpful.  It was thought that roles could be confused with job titles which may or may not reflect the accountabilities.

 The Scrum Team is now “focused on one objective at a time, the Product Goal.” This is a new and probably sits below “vision”. This is causing a discussion on whether it is technically ok for teams to work on a backlog that contains items from multiple products.  Otherwise, this is just an additional “commitment” that is now seen as part of the Product Backlog.

 Since there is no Dev Team, team size is now referred to as “typically 10 or fewer people” and includes 1 PO and 1 SM in that count.   The older guidance of “3 to 9” developers is still probably a good one with sizes around 4 – 6 being preferred by many teams.

 The Developers section (which replaces Dev Team) is much shorter when compared to the Dev Team in the previous version. Left out are items either attributed now to the Scrum Team or just left out entirely. One phrase omitted: “No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality.”   I don’t believe that changes the intent, however.

 Part of the Scrum Master definition has changed from “promoting and supporting Scrum” to “establishing Scrum.” 

 Added is the responsibility for the Scrum Master that: “The Scrum Master is accountable for the Scrum Team’s effectiveness.”  This is a new clarification though many of us have taught something similar for a long time.

 The reference to the Scrum Master being a “Servant Leader” has been changed to “true leaders.”  This one is interesting.  Some people have objected to “servant leader” though I think it’s a great model.  Now it would probably be a “good pattern” for a SM.

 The Scrum Master’s service to the PO has been paired down – I think primarily for brevity rather than any change in intent.

 Scrum Master’s service to the Org has several important small additions. (1) SMs now add training to leading and coaching the organization in Scrum adoption. (2) SMs add advising to planning Scrum implementations. (3) A small change in wording with the SM helps others understand the “empirical approach for complex work.” (4) the last two bullet points in the service to org are gone and replaced with a new one which reads “Removing barriers between stakeholders and Scrum Teams.”

by Steve Spearman from Agile for All