Every few years Ken Schwaber and Jeff Sutherland, the authors of Scrum, get together to update the Scrum Framework as it is defined in the Scrum Guide. These are the official rules of Scrum and they’ve gone through many iterations.
At the end of 2020, their latest version dropped, and it’s simply titled the 2020 Scrum Guide™. The goal was to simplify the framework and reduce unneeded portions, so the framework can be more accessible to a larger audience. This can best be seen in the decrease in size of the Scrum Guide (from 19 pages to 13).
They also made several changes to the framework, and while some aren’t that important, I believe some are worth considering.
Here I’ll outline what I think are the top 5 changes, tell you why they matter (or don’t), and also give you my opinion on the changes. This is by no means a comprehensive list of changes. It’s just the top 5 that I think are worth discussion.
Change 1: Accountabilities replace roles
CHANGE: The term “role” has been dropped in favor of the term “accountabilities” to label the individuals on a Scrum team.
IMPACT TO YOUR TEAM: For experienced teams - You can take or leave this change, since names and labels are more likely to be merely academic for you and your team. For new teams - You might decide simply to switch the words—or not.
BRIAN’S OPINION: Apparently some people thought that the term “role” meant job title. The authors wanted to find a term more like a position on a sports team. For example, all players are baseball players but each one is responsible for a specific duty: a catcher catches, a first baseman keeps track of happenings at first base. But your first baseman is of course also up to bat now and then, and in the same way any job title then might fill a specific Scrum team role without needing to hire someone with that job title. Scrum Masters don’t have to have “Scrum Master” on the resume; a project manager can play the role of Scrum Master as long as they adhere to what the Scrum Guide spells out for that role. “Accountabilities,” then, is an attempt to separate the two ideas: a role and a title aren’t the same thing.
The term “accountability,” though, doesn’t solve the problem. When most people (myself included) think of accountabilities, they think of responsibilities: “I am accountable for putting my dishes in the dishwasher.” The problem comes with the fact that I can be accountable for multiple things but the new Scrum Guide states that the Scrum team “consists of one Scrum Master, one product owner, and developers.” These terms represent some undefined word that contains multiple other accountabilities. For example, each developer is accountable for quality, creating a plan for the sprint, and holding one another accountable. That missing word sounds an awful lot like a role to me. If that’s a problem for some, stick with the sports theme of Scrum and call them positions. Regardless of how you think of them, they are parts that people step into in order to play Scrum. “Accountability” just doesn’t describe that, in my opinion, and will only add to the confusion.
Change 2: No more development team
CHANGE: There is no longer a development team, just developers.
Scrum Guide authors Jeff and Ken stated that they had always disliked having a “team within a team” by having a development team inside the Scrum team. In this latest version, they fixed that by getting rid of the development team concept. The Scrum team is the only team in Scrum now and it consists of three accountabilities: Scrum Master, product owner, and developers.
IMPACT TO YOUR TEAM: For experienced teams - This change is likely only cosmetic. And it harkens back to the past; we did once call them developers, not dev team. But do understand that this shift in language is to try to emphasize the “one team” concept.
For new teams - Simply understand that there is only the Scrum team now that is made up of three accountabilities: product owner, Scrum Master, and developers.
BRIAN’S OPINION: While I get the purpose of this change and agree that there is only one team in Scrum, I worry a bit about the unintended consequences of this change. This is mostly due to the next aspect of the new Scrum Guide: the guidelines for developers. Previous versions spelled out explicitly the rights and responsibilities of this group. Now that’s missing in the name of brevity. One phrase I am particularly sad to see go runs, “No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality.” While some might consider this implied and therefore not needed, I believe there are plenty of organizations that aren’t used to operating in this manner and need this particular prompt telling them that the how of building the product lies squarely with the developers.
On the surface, then, it should be a positive change. As practitioners though, we need to help organizations understand the intent of independence is still there even if it’s no longer spelled out explicitly.
As long as we are tinkering with names, I would have preferred to update this to something like producers or creators. Developer is a software-centric term and disinclines many outside of software from employing Scrum. I wish the new Scrum Guide had taken this chance to provide a word less connected to the software world.
Change 3: No more Servant Leaders
CHANGE: The Scrum Guide has dropped the term “Servant Leader” in describing Scrum Masters and replaced it with “true leader.”
IMPACT TO YOUR TEAM: For experienced teams - Likely no impact here unless “true leader” has an alternate meaning that isn’t clear. For new teams - Since you don’t have any history with this phrase, this likely has no impact to you.
BRIAN’S OPINION: I think this change is the hardest to understand of the bunch. What is offensive about Servant Leadership as a term? And what in the world is a “true leader?”
I can only speculate as to the reason for this change. Perhaps it’s connected to the movement in the tech world to drop the terms Master/Slave in reference to databases, since some people thought it could be considered a reference to slavery and therefore offensive. Whatever your opinion on that one, I did also hear some rumblings in agile circles that perhaps we should reconsider the term Scrum Master, and even Servant Leader, for the same reasons.
Servant Leadership has nothing to do with slavery. Servant Leadership was a movement begun by Robert Greenleaf in the 1970s that’s meant to paint the picture of a humble leader serving those who wish to be led. It’s an incredibly powerful paradigm shift that occurred in the business world—and the role of the Scrum Master has traditionally been linked to this term for good reasons. I said above that I think “true leader” is a meaningless phrase. There is no “true leader” movement or philosophy. It sounds as if someone wanted to keep the meaning of Servant Leadership but replace the words with something similar. It would be a shame if this is where the new term emerged; it would be based on misinformation and a lack of understanding of what Servant Leadership is.
I hope the authors will reconsider, that they’ll re-examine the heritage and political correctness of the term “Servant Leader.” I’d like the term to find its way back into a future version of the Scrum Guide.
Change 4: Adding in Commitments
CHANGE: Each Artifact now has an accompanying “Commitment”: Product Goal for Product Backlog, Sprint Goal for Sprint Backlog, and Definition of Done for the Increment.
IMPACT TO YOUR TEAM: For experienced teams - This should not impact your team provided you’ve already been working with a Product Vision. For new teams - You will hear less and less about a Product Vision and more about this Product Goal in Scrum. They seem to be generally synonymous.
BRIAN’S OPINION: This change is a bit more tricky. Of these commitments, Sprint Goal and Definition of Done both existed in previous versions of the Scrum Guide, but not as an attached commitment to their Artifacts. The Product Goal is the only new idea, at least when it comes to the Scrum Guide.
Most trainers and coaches have been teaching product owners for years about the benefits of having a Product Vision, which is the guiding force for the product. As Roman Pichler says, it is the product’s “true north.” Now let’s see how the new version of the Scrum Guide refers to the Product Goal:
“The Product Goal describes the future state of the product which can serve as a target for the Scrum Team to plan against.”
If you are having trouble seeing the difference between a Product Vision and this Product Goal, you are not alone. Why did the authors choose to ignore that the community was already using the term Product Vision and replace it with Product Goal? I can’t find a reason other than that it pairs better with Sprint Goal. If a case can be made for how Product Vision and Product Goal are different, I’ve not heard it yet. So if you are using Product Visions today and you start calling them Product Goals, that might be all you would have to do to technically align to the new Scrum Guide.
There is one small detail of this addition as it’s defined in the Scrum Guide that irks me. For both the Product Goal and the Sprint Goal, this new Scrum Guide says that these items are IN their respective backlogs. If it weren’t spelled out so explicitly, I wouldn’t give this a second thought. But how is it possible considering that the Product Backlog is made up of everything known that’s needed to produce the Product? The Sprint Backlog similarly contains everything known that is needed to produce the sprint’s Product Increment. In both cases, the backlog is a place of things to do: features, tasks, bugs, spikes, etc. How is a goal then IN the backlog? Unless we are redefining the backlog or creating special new sections of the backlogs for goals, it doesn’t seem to make sense that they are IN the backlogs. I yield the soap box.
Change 5: Sprint Planning three questions
CHANGE: Sprint Planning has expanded from two questions (WHAT and HOW) to three (WHY, WHAT, and HOW).
IMPACT TO YOUR TEAM: Small, if any.
BRIAN’S OPINION: For years now, the Sprint Planning event has had a goal of answering two questions: WHAT are we going to do and HOW are we going to accomplish it? In this latest version of the Scrum Guide, the authors have added the question up top that asks, “Why is this Sprint valuable?” They then go on to explain that the Scrum team collaborates to create a Sprint Goal.
None of that is new.
As part of the WHAT discussion, teams have always had a Sprint Goal that the product owner proposes and the whole Scrum team then collaborates to define. If we are being picky with words here, I’m not sure the Sprint Goal is giving us the WHY for the sprint. It’s giving us the goal of the sprint but not why that goal is important. Put another way, the Scrum team doesn’t have to justify their goal, they just have to define it.
In my mind then, this is a regular part of defining WHAT the team will work on. If your team needs three delineated questions to determine the Sprint Goal, the Product Backlog items, and the tasks to create them, feel free.
Asking two questions or three likely makes no difference to how Scrum teams run their sprints. I’ve yet to hear a valid explanation of why this was explicitly called out in the new Scrum Guide.
A Common Theme to These Changes
You’ve likely noticed a theme here. Most of the changes in this new version will not have a substantial impact to how you are running Scrum in your organization today. Sure, you might change the terms you use or you might answer a question slightly differently on a test, but otherwise you will not need to change a thing to adhere to this newest version of Scrum.
The bigger impact comes in what was removed. In order to make the Scrum Guide smaller, elements that some will see as key have been removed. If organizations remember the 2017 Scrum Guide and aren’t changing their methodology now, there may not be a problem. For new organizations adopting Scrum for the first time who don’t have that history to call upon, there might be crucial holes in the framework that will not be filled in a way consistent with Scrum’s historical strengths. I hope these organizations will seek out guidance to help with their lack of experience. If organizations are learning from the 2020 Scrum Guide alone, we may not see the impact of these changes for several years down the road.
For new teams, I suggest that they read the 2017 version in order to have a better understanding of the 2020 one.
My advice for established teams? Keep doing what you are doing—if it’s working for you. If not, inspect and adapt.
