With the bajillion articles written on it, you’ve probably seen that the creators of Scrum released the latest edition of their official guide to the framework, marking the first new revision since 2017. Good news! It’s slightly shorter, less dogmatic, less prescriptive, and reads less like a boring technical guide, and more like advice from a trusted friend.
And while we’ll explore some of the major changes, we’ll also dive into the little ones that could be easily missed but are no less important.
Big Scrum Guide Changes
The revised Scrum Guide has been tweaked at almost every level, with changes ranging from adjustments in vocabulary to the elimination of several sections altogether. Beyond the minor updates, however, there are a few overarching themes that represent some of the most significant changes in the framework’s history.
As Scrum continues to gain momentum, one thing is clear— this way of working is not just for software developers. In any industry with complex problems to solve, from public education to financial services, Scrum has steadily garnered a dedicated community of fanatical advocates.
In response to this growing popularity in other fields, the updated Scrum Guide utilizes fewer software-specific terms, broadening the scope of the language to highlight the adaptability of the framework.
Products = Services and Services = Products
In an effort to be more inclusive to other industries, the updated guide clarifies that the word “product” doesn’t have to be taken literally. As defined by the guide, “A product is a vehicle to deliver value. It has a clear boundary, known stakeholders, well-defined users, or customers. A product could be a service, a physical product, or something more abstract.”
Basically, Scrum can be useful as long as you’re working on something that will provide value to users. In our humble opinion (and also in truth), take it with a grain of salt as it doesn’t necessarily mean Scrum works for every project.
Commitments to Empiricism
At its core, the Scrum framework is dedicated to encouraging people to take ownership of their own work. In order to effectively take autonomy, however, team members must all be aligned on clear, singular goals. In the new guide, this is emphasized through a heightened focus on empiricism — creating a more cohesive working environment through commitment to goals, rather than tasks.
Through empiricism, practitioners are provided with the flexibility to learn from their experiences and adjust their approach accordingly. The revised guide makes several changes to Scrum ‘definitions’ in order to highlight the critical importance of empiricism:
- Sprint Goal. The 2020 Scrum Guide provides the Sprint Goal with a more explicitly defined purpose, calling it a “commitment by the Developers” that allows for “flexibility in terms of the exact work needed to achieve it.”
- Definition of Done. While the Definition of Done is also familiar for Scrum users, it is also now more clearly defined as “a formal description of the state of the Increment when it meets the quality measures required for the product.” This provides transparency for the Increment to the Scrum Team and their stakeholders.
- Product Goal. As one of the first newly introduced terms in the updated Scrum Guide, the Product Goal “describes a future state of the product which can serve as a target for the Scrum Team to plan against,” highlighting the empirical path to a longer-term objective.
Introduction of the Product Goal
While previous versions of the Scrum Guide have certainly underscored the importance of alignment within a team, this sense of shared purpose was further formalized in 2020 as the Product Goal.
Prior to the introduction of this concept, Scrum Teams relied primarily on a series of Sprint Goals, outlining short-term outcomes that could be achieved by the end of each Sprint.
Without having an overarching, long-term objective, however, work can quickly break down into a misaligned mess of unfocused, ad hoc Sprint Goals and activities. By providing a clear, measurable Product Goal — whether it’s an improvement in NPS or an increase in the number of monthly active users — Scrum Teams can more effectively map out a sustainable long-term objective.
Self-Organization Shifts to Self-Management
The Scrum framework champions the independence of individual contributors, asserting that team members themselves should decide who does what and how to do it. In the original Scrum Guide, this characteristic was described as a team’s ability to “self-organize.” In time, however, it became clear that the term “organization” simply wasn’t descriptive enough.
Okay, we’re organized, now what? Are we done here?
To help emphasize the true spirit of autonomy, the 2020 Scrum Guide revises the term from “self-organization” to “self-management.” This phrasing is more proactive, not only encompassing the capacity to organize your work, but also the ability to manage yourself.
Accountabilities Instead of ‘Roles’
While the various members of a Scrum Team clearly have different strengths to offer, separating the group into a collection of cookie-cutter positions isn’t always the best way to go. In reality, the different Scrum “roles” shouldn’t really serve as job descriptions, but a way to hold contributors accountable.
With the 2020 update, references to “roles” are now replaced with “accountabilities,” encouraging the team to adjust their focus to the shared goals, rather than titles. While the labels for these accountabilities remain the same— Scrum Master, Product Owner, and Developers— there’s more nuance in terms of who is responsible for what. This is meant to improve collaboration, pushing the team as a whole to better align on common objectives.
Changes You Might Have Missed
Imagine, you’re hanging out with your buddies having a beer, discussing work, and you blurt out something about Servant Leadership. The music stops, people quiet, a baby, somewhere, begins to cry. Your annoying colleague, Karen, leans over, “The term Servant Leadership doesn’t exist anymore.”
These scenarios are exactly what we’re going to help you avoid. Though the big changes are important, the little ones can still have a pretty big impact. Thanks Karen.
Sprint Planning Gets a “Why”
Sprint planning is a critical first step at the start of any iteration, providing the team with a clear picture of the work needing to be done. In the early versions of the Scrum Guide, Sprint planning focused on answering two important questions: “What can be done this Sprint?” and “How will the chosen work get done?”
While these two topics have served as the groundwork for guiding the Scrum Team’s work, they fail to address an even more important question— why?
Because the Sprint Goal is to increase the utility and value of the product it’s crucial for the Scrum Team to carefully consider how this Sprint will improve outcomes for their users. As a result, the updated Scrum Guide now also recommends that every Sprint Planning event begins with another important question: “Why is this Sprint valuable?”
Product Backlog Refinement is Even Less Prescriptive
The 2020 Scrum Guide offers plenty of new content, but it’s worth noting that some parts have been reduced significantly. The 2017 version spent a couple of paragraphs on this key activity, while the revised guide sums this activity up in a few sentences.
Confused? The upside is that for Scrum Teams who struggle with refining and managing their Product Backlogs, the updated guide gives them the flexibility to do whatever works best for them. In short, the Product Backlog is to be “refined as needed” to “increase understanding and confidence”.
No more Development Capacity
Timeboxing is an important component of almost everything in Scrum, but not every team has the same needs. While the 2017 Scrum Guide suggests teams should spend no more than 10 percent of their ‘Development Capacity’ refining the Product Backlog, the 2020 Scrum Guide defers to the team’s expertise, empowering the Scrum Team to decide how much time is needed.
Who is responsible for Increment Releases?
With the transition from “roles” to “accountabilities” comes an added level of ambiguity around certain responsibilities. Deciding how and when to release an increment, for example, is a task that once fell squarely within the domain of the Product Owner. The updated guide offers far less description around who owns this work, instead assigning responsibility to the entire Scrum Team.
This extends the common theme of deferring implementation details to practitioners, leaving the Scrum Team with an important question to answer for themselves: who is best suited to make these decisions?
Servant Leadership No More
Scrum Masters are “servant leaders,” right? The updated Scrum Guide insists this was never quite the right phrasing. The term “servant leader” has been misinterpreted far too often, the results being Scrum Masters behaving as servants without leadership. Instead, the phrase has been replaced with “true leaders who serve,” clarifying that Scrum Masters should offer leadership, guidance and service at every level of the organization.
In truth, this is what good leadership is all about— fearlessly leading by example, and guiding everyone around you towards a common purpose.
If you’re already like the dancing guy then you’ve got a leg up (see what we did there). You clearly know what it is to lead, but it’s important that you come armed with knowledge and experience to truly guide your team. And that is what Responsive Advisors can help with.
Much like the new version of the Scrum Guide, Responsive Advisors is not dogmatic or prescriptive in their teachings. As experts in the field, they actively lead Agile adoptions which gives them relevant, real-world knowledge of what’s going on in the industry. After a course with Responsive Advisors, you’ll be prepared for more than just the Agile certification– you’ll be ready to practice Agile and Scrum in the real world.