The new Scrum Guide is here. It’s been three years since the last update to the venerable guide was last published, and finally the new 2020 version has been released. Scrum is still Scrum, in all its simplicity. We are going to look at what’s new in this latest release.
Scrum is a framework to build complex products using an iterative and incremental process and it’s been around since 1995. The Scrum Guide itself is subject to the same rules of inspection and adaptation that are fundamental in Scrum, and over the years it’s been updated, improved, extended, or simplified as the larger Agile community learned about what worked and what didn’t, and provided feedback. The founders of Scrum, Jeff Sutherland and Ken Schwaber, incorporated the feedback and updated the Guide to reflect how Scrum is used today around the world.
There are several small changes in the 2020 edition and a few that are worth noting for their impact on the Scrum Teams. In general, the new Guide is less prescriptive on specific practices (after all, Scrum is a framework, not a methodology) and more clear on core components. One important thing to note, Scrum maintains its 5-3-3 structure, 5 events, 3 accountabilities, and 3 artifacts. The changes are not in the structure of the framework, but are more subtle details that have an impact on its implementation.
Scrum is for building products, not only software
At its origin, Scrum introduced a simple and effective framework to build better software using Agile principles. As the Agile adoption spread around the world, teams and organizations of all kinds started using Scrum. They used Scrum to build software products and, incrementally, to work on all kinds of projects, even non-software related. Legal teams, Marketing teams, Hardware teams, Aircraft teams (just to give some documented examples) reap benefits in productivity, risk reduction, and go-to-market by adopting Scrum.
The new Scrum Guide recognizes this by evolving its language to specify that while Scrum is used by software development teams around the world, it can be effectively used outside of the software realm as well.
This simple change, maybe a bit subtle, recognizes a reality that has for long been under-appreciated by the general public, and formally presents Scrum as a framework that can be used in a variety of contexts to build a variety of products.
There is only the Scrum Team
The concept of the Scrum Team – a cross-functional group of people whose responsibility is to build a product and deliver it to customers – has always been a staple of Scrum, bringing together a Product Owner, a Scrum Master, and a team of Developers. In previous versions, there was a dichotomy between the Product Owner on one side and the Development Team on the other. The Development Team was a team within the Scrum Team. This created in practice all sorts of contradictions and conflicts between the Product Owner and the Development Team.
In the new Scrum Guide the roles and relationship have been both simplified and clarified. The Scrum Team is now more clearly specified as composed by a Product Owner, a Scrum Master, and a number of Developers. Off goes the Development Team: there is no longer a sub-team within the Scrum Team. Instead, there is only the Scrum Team.
Each role maintains its own specific accountabilities. The change is not only semantic: by removing the team-within-the-team concept and making it clear that all these people belong to the same team, the Scrum Team, it creates a stronger commitment for everyone in delivering the Sprint Goal at the end of the Sprint. We are in this together.
The Scrum Team size also changes. Now there is no minimum or maximum size. However, Scrum recognizes that a Scrum Team typically has a size of 10 people or less, and that includes the Product Owner and the Scrum Master. The limited size of the Scrum Team optimizes for collaboration, transparency of the work, and for a sense of belonging to the same team.
Clear commitments associated to artifacts
Three artifacts have always been a staple in Scrum: the Product Backlog, the Sprint Backlog, and the Increment. They are now extended with commitments associated to each artifact that clearly define the expected end result of the work.
Product Goal
The Product Backlog is the list of all the work that the Scrum Team needs to do in order to create a working product. The Product Backlog is dynamic and emerges over time. Because of this, it changes over time.
To maintain a sense of direction and alignment towards a vision, the Product Goal is now associated to a Product Backlog. The Product Goal defines the commitment for the Scrum Team towards the end state of the work they are doing. The Product Backlog Items contained in the Product Backlog align towards the Product Goal so that over time that goal can be realized.
To describe the Product Goal you can use the Vision Canvas template. We have updated it to include a Product Goal section that aligns to the overall vision for the product.
Dave West offers a nice explanation of the Product Goal with examples.
Sprint Goal
The Sprint Goal was there before. Its role is now made a bit more clear: it provides a clear indication to the “Why” the Scrum Team is doing the work in the Sprint. What is the Scrum Team trying to achieve this Sprint? What is the overall goal of the Sprint?
With the new definition, the Sprint Goal becomes an integral part of the Sprint Backlog. With this, the Sprint Backlog represents the “What” (the list of work items selected to work on in the Sprint), the “How” (the plan on how to execute the work and create an Increment in the Sprint), and the “Why” (the Sprint Goal). During the Sprint, the actual work (the “What” and the “How”) may change. The Sprint Goal does not change and indicates the objective that the Scrum Team is trying to achieve by doing the work, it indicates the commitment by the Scrum Team for this Sprint.
Definition of Done
The Increment developed by the end of the Sprint contains all the work items done by the Scrum Team in the Sprint. To establish a set of criteria to enforce quality and make sure the work is completed to an acceptable standard, the team creates a Definition of Done.
The Increment needs to satisfy the Definition of Done, otherwise the work is not done and it should not be included in the Increment.
If a Product Backlog Item does not meet the Definition of Done, it cannot be released or even be presented at the Sprint Review. Instead, it returns to the Product Backlog for future consideration.
– Scrum Guide, 2020
Teams that don’t have a clear Definition of Done risk releasing work that is only partially completed, does not satisfy the standard of quality, or may require rework in the future. All of these conditions affect the productivity (and, over time, the morale) of the team.
By making the Definition of Done a clear commitment for the Increment, the Scrum Guide is now inviting all Scrum Teams to have a Definition of Done (and create one if they don’t have it) and make sure the work they do satisfies it.
Other notable changes
Scrum Master
The Scrum Master takes a central position in the new Guide. In fact, the Scrum Guide opens with one of the first sentences dedicated to the Scrum Master’s responsibilities:
Scrum requires a Scrum Master to foster an environment where:
A Product Owner orders the work for a complex problem into a Product Backlog.
The Scrum Team turns a selection of the work into an Increment of value during a Sprint.
The Scrum Team and its stakeholders inspect the results and adjust for the next Sprint
– Scrum Guide, 2020
The Scrum Master remains a servant leader for the Scrum Team and its role is expanded to service the organization: the SM now adds training to leading and coaching the organization in Scrum adoption; the SM advises and plans Scrum implementations; the SM removes barriers between stakeholders and the Scrum Team.
Daily Scrum format
Many Scrum Teams around the world perform the Daily Scrum (or standup) using a variation of three questions. While this can be a possible way to conduct the Daily Scrum, many teams have interpreted it as being the way to conduct it. However, the three question format is often not the most effective format for a Daily Scrum and in recognition of this it’s been removed from the Scrum Guide.
The idea is that the Scrum Team (and in particular the Developers within it) devise the format for their Daily Scrum that they find most effective. It could be three questions, it could be work item by work item review, it could be any other format that they find useful.
Action items from Retrospectives
It is a best practice for Scrum Teams to end a Retrospective with at least one action item and implement it in the next Sprint. This supports continuous improvement for the Scrum Team. The new Scrum Guide formalizes this by adding the sentence:
The most impactful improvements are addressed as soon as possible. They may even be added to the Sprint Backlog for the next Sprint.
– Scrum Guide, 2020
Three pillars of empiricism
Scrum is founded upon empiricism and in particular on the three pillars of transparency, inspection, and adaptation. The Scrum events and artifacts bring to life these three pillars.
The new Scrum Guide clarifies how the pillars are connected to each other and how they exist in their entirety:
Transparency enables inspection. Inspection without transparency is misleading and wasteful.
…
Inspection enables adaptation. Inspection without adaptation is considered pointless. Scrum events are designed to provoke change.
– Scrum Guide, 2020
Refinement activities
Refinement of the Product Backlog is a continuous activity for the Product Owner – this is what makes the Product Backlog dynamic and emergent after all. From time to time the Product Owner may need help from others to clarify the scope of some of the work, understand dependencies and technical details, or keep everyone aligned on the work that’s been done. The Product Owner may include Developers, stakeholders, business partners in other divisions, maybe other Product Owners. And they may meet periodically to inspect the future work in the Backlog and prepare for it.
The point is, everyone performs refinement in different ways, specific to their work context and organizational needs. So, while refinement activities are a good practice for any Scrum Team, prescribing a specific way feels a little bit constrained. In recognition of this, the new Scrum Guide has removed specific instructions and constraints on refinement activities.
Refinement remains a good practice for any Product Owner, and decisions on how to perform it and how often remain a prerogative of the Scrum Team.
Learn more about Scrum in this article.
Download the Scrum Guide from https://scrumguides.org/
