Scrum Guide 2020 - What's Changed?

Last month (November 2020) the Scrum Guide was updated. Here's a quick summary of what's changed, what's new and what's been removed.

Scrum is Still Scrum

The first thing to say is that Scrum is still scrum. That’s something the team behind the new guide stressed multiple times and it’s true that if you’re already doing good scrum then the changes won’t make much difference to you. The updates bring the Scrum guide more in line with good practice that high-performing scrum teams already do.

The new guide is shorter and more concise. The goal has been to remove some ambiguity whilst also making it less prescriptive. It seeks to outline a framework that can be truly adapted to any situation. That means you have to layer on your own processes and tools to make it work in your context and environment.

Let’s take a look at some of the key areas where changes have been made.

Scrum Team

"The entire Scrum Team is accountable for creating a valuable, useful Increment every Sprint."

The term Development Team has been replaced with just Developers. They still mean all people on the scrum team who are accountable for delivering the work, for example software engineers and QA engineers. And the Developers are still required to self-organize to deliver that work. This is purely a text change to cater for those who interpreted the old language as meaning there was a team within the Scrum Team or that there was some sort of hierarchy between Product Owners, Scrum Masters and Developers.

"Developers are accountable for:

- Creating a plan for the Sprint, the Sprint Backlog;

- Instilling quality by adhering to a Definition of Done;

- Adapting their plan each day toward the Sprint Goal; and,

- Holding each other accountable as professionals."

The size of a scrum team has been simplified to say it should be “typically 10 or fewer”. It’s still the case that smaller teams are better, provided they have all the skills necessary to create a Done Increment.

Lastly, the term self-organizing has been replaced by self-managing. Really this again is just a text change though. The meaning is still that they internally decide who does what, when, and how.

Scrum Masters

There’s only one small subtle change here, from being servant-leaders to “true leaders who serve the Scrum Team and the larger organization.” Again, this doesn’t actually change what scrum is, rather it seeks to clarify the role. There are some who interpreted the role by focussing on being a servant and ignored the leadership element, instead merely performing secretarial or facilitation duties.

"The Scrum Master is accountable for the Scrum Team’s effectiveness."

The guide doesn’t go into detail on how the Scrum Master should lead the team but mentions coaching, helping the team to focus and helping to remove impediments to progress (such as by driving the right conversations).

Product Goal

"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."

"The Product Goal describes a future state of the product which can serve as a target for the Scrum Team to plan against."

The concept of articulating a vision or objective for the product and organising around that isn’t new. The previous version of the guide stated that “the increment is a step toward a vision or goal.” The new guide expands on that by explicitly defining something called a Product Goal.

The Product Goal is a longer-term objective for the Scrum Team to focus on. It’s something that individual sprints collectively build towards, and the team should only work on one goal at a time.

The Product Owner is accountable for developing and explicitly communicating the Product Goal.

Sprint Planning

Sprint planning now explicitly covers 3 topics - why, what, and how. Again, most sprint teams will already be doing this in some way.

The Product Owner articulates why the next sprint increment will be valuable to the business and then collaborates with the team to define a Sprint Goal. The Sprint Goal is the why of the sprint.

Then the team moves on to discuss what can be done within the sprint to achieve the sprint goal. This includes selecting items from the Product Backlog, discussing and refining as necessary, reviewing their past performance and considering upcoming capacity.

Then thirdly the team discusses how the chosen work will be completed in accordance with the Definition of Done. The work is planned by the Developers, often by decomposing Product Backlog items into smaller work items of one day or less.

Daily Scrum

The purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work.

Whilst the traditional 3 questions (what did I do yesterday, what am I committing to doing today, do I see any impediments) haven’t formed a core part of scrum for some years, any mention of them as even a suggested approach has been dropped.

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 creates focus and improves self-management.

Definition of Done

The definition of done is clearly defined as a formal description of the state of the Increment when it meets the quality measures required for the product.

What has been removed?

The guide has been simplified and streamlined, partly to make it easier to consume but also to make it less prescriptive and more applicable to situations outside of software development.

Some of the things that got removed are:

• The requirement that an improvement identified in the sprint retrospective is added to the next sprint backlog
• The three questions for the Daily Scrum.
• The specific activities to be done in the sprint review
• Meeting after the Daily Scrum for detailed discussions, re-planning, etc. 

That doesn’t mean these ideas are no longer relevant. Just because they aren’t explicitly called out in the scrum guide doesn’t mean a team should stop doing them or that they aren’t useful for your situation. Rather, the guide is saying they are not mandatory and each team should decide which good practices would be most applicable to them.

As an example, some teams might not always be able to address the top issue raised in the retrospective for some reason. In which case they can still follow scrum whilst being more flexible in their approach, although they should be asking themselves why they aren’t focussing on addressing the issues. Remember, inspection without adaptation is pointless.