Two motivations drove the update to the Scrum Guide, which was delivered last month. The original creators of Scrum — Ken Schwaber and Jeff Sutherland — described their goals:
- To provide better support for the growing number of teams using Scrum outside of Software Development. Scrum is being used by product teams working on problems ranging from gene editing, car design to spaceship development. It is also being used outside of the product world in marketing, legal, and even in the school classroom. The parts of the 2017 Guide applicable to those contexts contained language that made it harder for those teams, new to Scrum, to adopt the ideas.
- As Scrum is used by thousands of people every day, those practitioners have provided feedback to Ken and Jeff encouraging changes.
The 2020 Scrum Guide reflects those two motivations. The release notes take those motivations further, describing eight themes.
- Less prescriptive
- One team focused on one product
- The introduction of the Product Goal
- Artifact commitments
- Replacing self-organized with self-managed
- Three Sprint Planning topics
- And a general simplification of language.
This release is intended by Ken and Jeff to make the Guide more usable, accessible, and inclusive.
The fight against prescription and best practice
Ultimately, with the release of the 2020 Scrum Guide, Scrum has not changed. Yes, some of the words may be different and there has been some increased clarity on topics like Definition of Done and the addition of the Product Goal, but the essence of Scrum is the same. It is a framework-based empirical process for continuous inspection and adaption. The one thing the updated Guide did was remind everyone is that complex problems make a prescriptive process difficult. Over the last several years, lots of things were added to the Guide — things that make sense, or that help adoption; but for each thing that was added there was always the risk that this prescription did not apply to everyone. Every additional sentence added complexity and potentially challenged the use of Scrum. Ultimately the Scrum Guide wants to provide a definitive description of Scrum that can be applied in every situation where Scrum makes sense to be used.
That means that the Guide has to describe the bare minimum. With the release of this version of the Guide, Ken and Jeff went back to the basics describing Scrum without the extra prescription. For example, asking the three questions at the Daily Scrum or always adding something from the Retrospective in the next Sprint might be very useful and can be used, but they should not be in the Guide as there are times that they do not make sense. Scrum is NOT a methodology, it is a framework. That means that people are required to add practices and prescriptions to make it work in their context. When solving complex problems, you don’t know everything that will happen and learn as you go, so an overly prescriptive methodology just doesn’t work. Instead, Scrum provides a framework that allows people to add on top of, to result in a process that works in their context, for their team and organization.
It is ultimately about delivering value
With the 2020 update to the Scrum Guide, commitments were added to each artifact. These commitments provide a place to put a ‘thing’ that helps improve transparency. In the case of the Sprint Backlog, the commitment is the Sprint Goal. For the Increment, it is the Definition of Done. Both the Sprint Goal and Definition of Done were already in the Scrum Guide, though previously not directly connected to the artifact.
For the Product Backlog, a new commitment was added called the Product Goal. In a nutshell, the Product Goal provides context to the Product Backlog. It can be thought of as the ‘why’ we are doing all this work and set a longer-term vision for where we are heading. It can be used as the elevator pitch to ‘what is the Scrum Team working on?’ The word Goal is intentional as it describes two things:
- It is something to strive for, and
- It is measurable when you have attained it.
The Scrum Guide does not prescribe what the details of a Product Goal are allowing; therefore Scrum Teams can form the goal for their context. For instance, some Scrum Teams may work toward a quarterly Product Goal that is very focused, another Scrum Team might have a Product Goal that is very aspirational and high level. Context is everything when determining the Product Goal.
The addition of the Product Goal was motivated by the desire to make Scrum more usable for different contexts and to double down on the transparency required in Scrum. A Scrum Team by its very nature is formed in pursuit of something. That is universal for all Scrum Teams, immaterial of the context. By making that more explicit it will, I hope, make the use of Scrum more attractive to any team that has a goal in a complex environment. It also encourages a clearer connection between the Product Goal, the Scrum Team, and their work. This allows work to be inspected in the context of the Product Goal. This is particularly true of the Sprint Review, where the Increment is discussed. By having a Product Goal front and center at the Sprint Review, great clarity and learning is possible.
How many times have you attended a review where everyone is so focused on what is being reviewed they forgot the ultimate context? Of course, great Scrum Teams have been doing this already, but adding a Product Goal makes it more explicit.
It is Scrum, but clearer and more direct
Scrum turned 25 in October, and the first documented version was over 100 pages long. During those 25 years, it has shrunk and grown based on feedback and learning from a methodology to a framework. Elements were changed, new elements added and elements removed. But throughout that time the basics have never wavered. All you really need to remember is the simple idea of:
- An empowered team
- Focused on a problem
- Working empirically.
The framework provides the ‘dance steps’ to make it real, but then it is up to you to enhance it to meet your context.
