The Latest Scrum Guide, often referred to as the definitive rulebook for the Scrum framework, is intentionally brief and non-prescriptive. Its creators, Ken Schwaber and Jeff Sutherland, periodically refine it to make the framework simpler, clearer, and more effective. The latest major revisions reflect a significant step in this evolution, moving away from outdated terminology and placing a renewed emphasis on team empowerment and clear objective setting.
The changes aren’t about introducing complexity; they are about reinforcing the underlying principles of empiricism and lean thinking. If your team adopted Scrum years ago, understanding these key updates is essential to ensuring you are running the modern, most efficient version of the framework.
1. From “Self-Organizing” to “Self-Managing”: The Biggest Cultural Leap
The single most pivotal change in the latest guide is the replacement of the term “self-organizing” with “self-managing.”
While “self-organizing” meant that the Development Team managed how the work was done, the new “self-managing” term expands this authority significantly. A self-managing Scrum Team is now empowered to manage three crucial aspects:
- Who: The team decides who does what work.
- How: The team determines the best way to accomplish the work.
- What (within the Sprint Goal): The team, composed of the Scrum Master, Product Owner, and Developers, manages the work necessary to achieve the Sprint Goal.
This shift firmly establishes that the Scrum Team is accountable for managing its processes and its immediate scope, reinforcing autonomy and removing any potential ambiguity about external management control. The organization must respect this authority for Scrum to work.
Also see: Do You Need Both a Scrum Master and a Project Manager?
2. Introducing the Product Goal: The North Star of the Product Backlog
In previous versions of the Guide, teams often struggled to articulate the long-term objective that guided their work. The latest revision solves this by introducing the Product Goal.
The Product Goal is a required element that serves as the long-term objective for the Scrum Team. Everything the Scrum Team does—from refining the Product Backlog to planning the Sprint—is done in service of achieving or moving toward this goal.
- Clarity and Focus: The Product Goal provides the necessary context and strategic direction for the Scrum Team. A Product Backlog item is merely a feature; the Product Goal is the ultimate value proposition.
- Accountability: The Scrum Team must fulfill one Product Goal before taking on the next. It acts as a clear, single “North Star” that prevents the team from losing focus on the broader vision.
This change links every sprint’s effort directly to a greater, long-term business outcome, greatly enhancing stakeholder alignment.
3. The Three Commitments: Defining Quality and Focus
To bring greater transparency and focus to the three Scrum Artifacts (Product Backlog, Sprint Backlog, and Increment), the latest Guide introduces the concept of Commitments.
Previously, the Definition of Done (DoD) was the only formal commitment. Now, each artifact has a corresponding commitment:
| Scrum Artifact | Commitment | Purpose |
|---|---|---|
| Product Backlog | Product Goal | Provides the long-term vision and purpose for the product. |
| Sprint Backlog | Sprint Goal | Provides a single, cohesive objective for the Sprint. |
| Increment | Definition of Done (DoD) | Ensures quality and defines the state where product backlog items meet the required quality measures for release. |
By explicitly tying a commitment to each artifact, the framework creates immediate transparency and reinforces empiricism. The commitments guide the inspection and adaptation that occur during the Scrum events.
4. Simplified Language and the Evolution of the Daily Scrum
The updated Guide removes overly specific or prescriptive language, making the framework more inclusive and universally applicable.
The Daily Scrum is Less Prescriptive
The former, classic “three questions” format of the Daily Scrum—What did you do yesterday? What will you do today? Are there any impediments?—has been removed.
The intent of the Daily Scrum remains the same: to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary. The new Guide simply states: “The Developers can select whatever structure and techniques they want, as long as their Daily Scrum focuses on progress toward the Sprint Goal and produces an actionable plan for the next day of work.” This change reaffirms the self-managing nature of the Developers, allowing them to tailor the event to their specific context and needs.
The Team is Simplified
The term “Development Team” has been removed, and the entire team is now simply referred to as the “Scrum Team,” which consists of:
- The Product Owner: Accountable for maximizing the value of the product resulting from the work of the Scrum Team.
- The Scrum Master: Accountable for establishing Scrum as defined in the Guide.
- Developers: Accountable for creating any aspect of a usable Increment each Sprint.
This unified terminology emphasizes that everyone on the Scrum Team works toward the same objective—the Product Goal—with no hierarchy or sub-teams.
Summary
The revisions in the latest Scrum Guide are a masterclass in simplification. By shifting to “self-managing,” introducing the “Product Goal,” and formalizing the “Three Commitments,” the creators have made the framework more focused on outcomes, less prescriptive, and more resilient in diverse environments.
For your team, the next step is not just reading the Guide, but reflecting on these key changes: Are your teams truly self-managing? Do you have a single, transparent Product Goal that acts as your North Star? By embracing these revisions, you can unlock greater autonomy, drive higher quality, and ensure your Scrum implementation is delivering maximum value to the business.
