Why the Scrum Guide?
On 11/18, a new version of the Scrum Guide was released. This was the first major revision since 2017! This is the location where Ken Schwaber and Jeff Sutherland come together to agree upon “What is Scrum?”
Most (all?) major Agile scaling frameworks build on Scrum. It’s amazing how many Scrum Masters aren’t actually familiar with the Scrum Guide!
The Scrum Guide calls out 7 major changes to the Scrum Guide, which I’ve condensed into the 6 topics below:
1. Lighter & Less Prescriptive
The Scrum Guide is down to 11 pages from 17, and has been made more broadly applicable. Language referring to software has been removed, and simpler language has been implemented.
The Scrum Guide seems to be moving to be more broadly applicable across domains and contexts. The Scrum Events are less prescriptive than they previously were. For example, the Three Questions have been removed from the Daily Scrum section.
These small changes will allow the Scrum Guide to be applicable in more domains, which can only be a good thing for Scrum.
2. Sprint Goal, Definition of Done, and Product Goal Linked to Their Artifacts
This is perhaps the most consequential change to the Scrum Guide. While all three Commitments existed before, they were loosely defined. They’ve been called out explicitly as “Commitments” and tied directly to the Scrum Artifact of which they support.
Each Artifact can be thought of as a unit of delivered work. Each Artifact now has an associated commitment that allows Stakeholders and the Scrum Team to understand what is expected within the Artifact.
| Artifact | Commitment |
| Product Backlog | Product Goal |
| Sprint Backlog | Sprint Goal |
| Increment | Definition of Done |
This addition will be a great reminder for teams about the different levels of commitments that exist within the framework. I hope this encourages Scrum teams to avoid glossing over these important commitments.
3. Product Goal
The Product Goal is completely new terminology that is referenced in the change listed above about commitments and emphasizes the importance of having a longer-term vision for your product.
Though it seems obvious to look ahead, it’s very easy for Scrum teams to lose the forest for the trees while executing their sprints. In my opinion, one of the many reasons that Agile scaling frameworks are so popular is to help support long-term planning. I love that the Scrum Guide is being more explicit about the importance of longer range planning.
4. One Team
The phrase “Development Team” has been removed from the Scrum Guide to avoid the idea of a “team within a team”.
In practice, I often hear the phrase “core team,” which is another key signal of the existence of a team within the team.
The Scrum Guide has made some subtle changes to drive home the idea that there is a single Scrum Team with 3 roles – a Product Owner, a Scrum Master, and Developers. Developers is explicitly defined as any team member who does the work, even though it is very software-specific language. I do wonder if this language will change to be more generic in a future Scrum Guide update.
5. Self-Managing Instead of Self-Organizing
This is a change that is so subtle that I’m not sure why the authors called it out as one of their most important changes. The terms are generally interchangeable in common usage, and even the Agile Manifesto Principles use the term “Self-Organizing.”
The authors of the Scrum Guide believe that self-organizing means that the team defines when and how the product is built. They believe that self-managing means that the team defines when, how, and what is built (emphasis mine).
I believe this is intended to reinforce the change listed above about One Team – reemphasizing the idea that the Product Owner is a part of the Team and the Team is defining what gets built.
6. Sprint Planning Addition – “Why”
Answering the questions “What” (can be built) and “How” (will it get done) have always been a part of the Sprint Planning event. With the new update, the question “Why” has been added – instructing the teams to answer the question “why is this sprint valuable?”
I think this is a great addition to remind teams not to hyper focus on the tactical things being built – similar to reasoning behind the Product Goal.
Final Thoughts
A lot of these changes are subtle, but I do think they are moving the Scrum Guide forward, which is always great. I look forward to see what future enhancements will be made in future versions.
Will Talks Tech 