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

You can also listen to this post in our ongoing podcast.

Are you excited about the new Scrum Guide? We certainly are, if only because every version makes it more clear what Scrum is really about — which is also our mission.

The Scrum framework itself is subject to empiricism too, as evidenced by the new version of the Scrum Guide that was released on November 18. Its creators, Ken Schwaber and Jeff Sutherland, use each increment to improve how the Scrum framework is described and what teams and organizations should be focusing on. As stewards for Scrum.org, it has been a pleasure to follow the discussions leading up to this release and contribute to it with our feedback.

In this post, we take a look at the four most significant changes and why they were made. While it is tempting to talk about all the nitty-gritty linguistic changes, we believe it is more helpful to understand the underlying patterns and how they reinforce what Scrum has always been about.

 

1. Scrum Teams commit to a single Product Goal

Scrum is pointless without a focus on valuable outcomes. This has always been the case. At the same time, many organizations and teams continue to approach Scrum from a mechanical perspective that is only limited to the IT department. They pay more attention to the roles, the events, and the artifacts than to the overarching purpose of the Scrum framework to deliver valuable outcomes. More attention goes to the vehicle of Scrum than to where it's supposed to take you.

“More attention goes to the vehicle of Scrum than to where it’s supposed to take you.”

This is why clear and singular goals matter so much. Goals give meaning and purpose to the work of Scrum Teams. Goals also provide focus and act as a touchstone to base decisions on. This was already clear in how the Scrum Guide treats Sprint Goals. When Scrum Teams don’t have a single goal for their current Sprint, the goal then implicitly becomes to “complete all the work on the Sprint Backlog”. The Scrum Guide never intended the Sprint Backlog as a static selection of items that, once selected during Sprint Planning, can never change during the Sprint. On the contrary; in complex work and in complex environments, the scope of what needs to be done in a Sprint is likely to change from day to day as insights emerge, problems are discovered and oversights detected. And without a clear and singular goal for a Sprint, how can Scrum Teams possibly decide what is important and what isn’t. Without a singular goal, complex work will be ad-hoc and highly stressful.

This is why the new Scrum Guide puts an even stronger emphasis on clear and singular goals that capture what is valuable about the work. While it already included a single “Sprint Goal”, it now (formally) adds to that a single “Product Goal” that the Scrum Team commits to.

To give focus to what goes on the Product Backlog, and in what order, the Scrum Team commits to a single, high-level and long-term product objective called the “Product Goal”. There can only one “Product Goal” at a time, regardless of how many Scrum Teams work on a product. If that goal is achieved or abandoned, a new one is formulated. It is up to Scrum Teams and their stakeholders to discover the best way to capture a Product Goal in such a way that it gives them a singular focus on what is valuable and important about the work. Obviously, the Product Goal is likely to evolve as teams work towards achieving it — it isn’t intended as a static goal.

I believe that this is an excellent addition to the Scrum Guide and helps to distinguish great Scrum Teams and excellent Product Owners — who tend to work from clear goals — from their more mechanical counterparts. It is also entirely likely that many Scrum Teams will struggle with this requirement. In many organizations and environments, the value of shared and singular goals and their influence on focus, morale, and value isn’t understood. By emphasizing goals — Sprint Goals and Product Goals — even more strongly as a requirement, and not a nice-to-have, the Scrum Guide can make even more organizational impediments visible.

2. From Roles to Accountabilities

Over the years, the roles of the Scrum framework slowly turned into common job titles. A simple search on LinkedIn yields hundreds of thousands of people with “Scrum Master” or “Product Owner” as their job title. This is a victory in one sense, and a loss in another sense.

A common observation, and one we also make, is that the focus on job titles often distracts from their accountabilities as intended by the Scrum Guide. Many Scrum Masters fill their entire week with the facilitation of Scrum events for their various Scrum Teams and nothing more. Many Product Owners fill their week translating orders from their stakeholders to requirements, without any mandate to make decisions about the product or its strategy. The painful reality is that they are not, in actuality, Scrum Masters and Product Owners. They merely pretend to be — by their own choice, because they don’t know any better or because they’re not enabled to by their organization.

The new Scrum Guide attempts to correct this by referring to “Accountabilities” instead of “Roles”. This further emphasizes that the Scrum framework isn’t a collection of job titles, but a collection of accountabilities to develop a product in an empirical manner. It doesn’t matter whether your formal job title is “Scrum Master”, “Project Manager”, “Developer” or “Professional Clown” — if you honor the accountabilities of the Scrum Master, then that is what you are for the Scrum framework.

“This further emphasizes that the Scrum framework isn’t a collection of job titles, but a collection of accountabilities to develop a product in an empirical manner.”

I believe this is a good change and one that emphasizes what it is that Scrum Masters, Product Owners, and Developers should be spending their time on. Maybe it also allows us to stop discussions over whether or not a Scrum Master can be a Developer, or whether a Project Manager can act as Product Owner.

3. Three Commitments To Uphold Empiricism

The mechanical perspective on Scrum that I described earlier also results in a lack of commitment. Because it focuses only on the mechanics of Scrum — its roles, events, and artifacts — and doesn’t bother itself with clear and singular goals, it loses the most powerful way to create cohesion and autonomy within and between teams that operate in complex environments. By its very nature, complex work is deeply unpredictable. Even though many mechanically-inclined organizations still attempt to do so, you can’t simply hand teams a detailed list of specifications and expect a successful outcome. This command-and-control style of management limits the creativity, expertise, and experience to that of the manager who decides what needs to be done by whom.

The Scrum framework, in all its iterations, has always been about enabling the people who do the work to take control of that work. This expands the potential creativity, expertise, and experience to everyone who is doing the work. This level of autonomy naturally requires a wholly different style of management. One way to create cohesion in these high-autonomy environments is through clear, singular goals that give direction without dictating the work in detail — that is up to the experience of professionals.

“The Scrum framework, in all its iterations, has always been about enabling the people who do the work to take control of that work.”

The new Scrum Guide makes three goals, three commitments to those goals, and three ways to uphold empiricism, explicit:

1. The Scrum Team agrees on a single Sprint Goal at the start of every Sprint to guide the work and the decisions they will need to make during the Sprint. The people who do this work — the Developers — commit to working together towards this goal. The work that is needed for this is continuously updated and made transparent on the Sprint Backlog.
2. The Scrum Team agrees on a single Product Goal to guide the work and the decisions they will need to make during the development of a product. This work that is needed for this and the decisions that are made to update it are continuously made transparent on the Product Backlog. 
3. The Scrum Team agrees on a Definition of Done that describes the quality guidelines that they adhere to in order to deliver high-quality Increments to their stakeholders. The Developers commit to these guidelines and make it transparent through the Done Increments they deliver.

All three commitments exist to to uphold empiricism to the commitment to valuable goals. We believe that this change makes it more clear how cohesion between autonomous teams and professionals is created through a commitment to goals — not to specific tasks.

4. Shorter and even less prescriptive …

The Scrum framework is just that, a framework. It is necessarily incomplete because it can’t possibly account for every context, every environment, and every eventuality where it is used. This perfectly fits with the complex work it is designed for; here, too, professionals have the autonomy to fill in the details based on what works best for them. In a sense, the Scrum framework only sets the goalposts for an empirical approach and trusts in the experience and creativity of the players to decide how to best play the game.

“The Scrum framework only sets the goalposts for an empirical approach and trusts in the experience and creativity of the players to decide how to best play the game.”

If you take a look at earlier iterations of the Scrum Guide, it's easy to notice how to Scrum Guide has become less and less prescriptive over the years. Older versions recommended specific practices, like burn-down charts, specific questions to ask during the Daily Scrum, and the practice of letting Scrum Masters facilitate the Daily Scrum. We’ve learned that these practices are not always helpful. So the updated Scrum Guide continues the trend of being less prescriptive. There is no longer even a mention of the three questions to ask during a Daily Scrum, there is no longer a requirement on the number of improvements from a Sprint Retrospective that should end up on a Sprint Backlog and the overall language has been softened to create more space for local solutions. 

The changes emphasize that Scrum looks differently depending on where it is used. What works for software teams, may not work well for teams that use Scrum for scientific research or organizational change. And that’s great! One potential downside we see of this increasing abstraction away from specific situations is that a reading of the Scrum Guide alone won’t answer all those practical questions. And while we wholeheartedly agree that it shouldn’t, it requires that we — as a community of Scrum practitioners — step up to support and help our peers to find what works best for them. And that we spread Liberating Structures far and wide as a way to help teams explore, invent and identify what works for them.

Other changes

Aside from the four larger changes we addressed, and what they reveal about what matters about Scrum, there are also other changes worth mentioning:

• Instead of “self-organizing Scrum Teams”, the Scrum Guide now uses “self-managing Scrum Teams” to capture the high degree of autonomy that teams need to work effectively in complex environments. Coincidentally, this is the same suggestion we make in our book, the Zombie Scrum Survival Guide, when we analyze how self-organization and self-management are different things, and the Scrum Guide should’ve used “self-managing” instead.
• The Scrum Guide now makes explicit that Scrum Teams can deliver one or more Increments during a Sprint. In a Sprint, an Increment is created the moment a Product Backlog item is completed. If possible and desired by the Product Owner, each Increment can be released to stakeholders before the end of the Sprint. 
• The Scrum Guide replaced the term “Development Team” with, simply, “Developers”. This removes the idea of there being “another” team within the Scrum Team. For the Scrum Guide, everyone in the Scrum Team who contributes to achieving the Sprint Goal is considered a “Developer”, regardless of their job titles and skills. This further emphasizes that Scrum is about the accountabilities, and not job titles or roles.
• The Scrum Guide now emphasizes that the first step of Sprint Planning is to talk about why the Sprint is valuable (to stakeholders) in the first place. When the purpose is clear, the selection of work is performed to make that possible, followed by a decomposition of work for the first few days. This further emphasizes that Scrum is about valuable outcomes.
• The Scrum Guide no longer uses the word “meeting” in conjunction with the Scrum Events. Although the various Scrum Events can take the shape of formal meetings, you can do them however they work best for you. In many cases, a traditional meeting where a dozen people are sitting around a conference table isn’t probably the best way to go about it.
• The use of “Servant Leadership” in the Scrum Guide has been dropped in favor of just “Leadership”. The reasoning here is that “Servant Leadership” is a particular practice that Scrum Masters use to support their teams and organizations. While we understand the reasoning, we don’t fully agree with this change if we’re honest. We don’t agree that “Servant Leadership” is merely a practice. Instead, it is a philosophy on leadership that is deeply grounded in putting others in a position where they can lead. We’re worried that “leadership” is too easily interpreted in terms of traditional perspectives on leadership: direct, tell others what to do, and command and control.

A framework for help people and teams solve complex problems

“Scrum is still Scrum” was a recurring message within Scrum.org. If anything, the changes to the Scrum Guide are designed to make it more clear what is important about Scrum and what isn’t. While it might be tempting to engage in deep (almost theological) debates about individual words and phrasings in the Scrum Guide, it's good to remind ourselves of the purpose of the Scrum framework. It exists to help people and teams solve complex problems. And because those problems and their solutions tend to be highly unpredictable, they do well to work in small incremental steps towards a clear and valuable goal, using each increment to check if they’re still moving in the right direction. That’s all, really. And the new Scrum Guide brings that home even better than earlier iterations.

Yet, for all its changes, a new Scrum Guide is not going to magically resolve all those flawed implementations. A major challenge remains that many people never bother to read the Scrum Guide, or make an effort to understand its purpose. From there, it is easy to descend into Zombie Scrum. So this new Scrum Guide presents us — as a community — with a lovely challenge to find novel and creative ways to spread the message to those who wouldn’t go look for it on their own. Lets work together to bring this message to our managers, customers and stakeholders!

You can download a free PDF of the Scrum framework here.