The authors of Scrum, Ken Schwaber and Jeff Sutherland, work together after every few years to update the Scrum Framework as it is defined in the Scrum Guide. The Scrum guide, or the official rules of Scrum, have gone through many changes over the years.
The latest version of the Scrum Guide dropped at the end of 2020, and it’s simply titled the 2020 Scrum Guide™. The aim behind this last update was to reduce unneeded portions and to simplify the framework so that more people can access and benefit from the Scrum Guide framework. This can best be seen in the size of the Scrum Guide which decreased from 19 pages to only 13 pages.
The first version of the Scrum Guide did not appear until 2010, even though Scrum had its beginnings in the ’90s. Since 2010, the Scrum Guide has been getting increasingly popular, especially with the IT crowd. The framework of the Scrum Guide continues to adapt to the ever-changing reality and the needs of people.
The latest scrum guide updates saw the release of the 5th version of the Scrum Guide in 2020. A number of changes have been made to the framework, while we believe some are worth considering, some aren’t that important. Some very important changes have been made to the Scrum Guide over the years and we will discuss why there was a need for these changes.
Motivations behind the latest update
Two motivations drove the latest change or the update to the Scrum Guide, which was delivered in 2020. The original creators of Scrum described both of these goals.
The first is to provide better support for the growing number of teams that use Scrum in different industries. Product teams use the Scrum Guide while working on different kinds of problems, ranging from spaceship development to car design and even gene editing. Scrum is also being used in so many other places, like marketing and even in school classrooms. The previous update of the 2017 Guide contained language that would create hardships for such teams that are new to Scrum and want to adopt the ideas.
The second motivation is attributable to the fact that Scrum is used by thousands of people every day. These users provide feedback to the creators of Scrum, Ken and Jeff, and encourage changes. The release notes of 2020 Scrum Guide describe themes, which reflect both these motivations. This includes the introduction of the Product Goal, artifact commitments, three Sprint Planning topics, replacing self-organized with self-managed, one team to focus on one product, the framework is now less prescriptive, and a general simplification of language.
The creators of the Scrum Guide intend to make Scrum more usable, accessible, and inclusive.
Delivering Value
In the Scrum Guide 2020 commitments were added to every artifact and these commitments provide a place to put a “thing” that can help achieve a high level of transparency. For the Sprint Backlog, the commitment is the Sprint Goal and in the case of the Increment, it is the Definition of Done. While the Definition of Done and the Sprint Goal already did exist in the previous versions of the Scrum Guide, however, there were no direct connections to the artifact previously.
A new commitment was added for the Product Backlog, it’s called the Product Goal. In short, the Product Goal will provide context to the Product Backlog. We could see it as the “why” we do all that work and set goals to figure out where we are heading. The word “Goal” is important here as it suggests that it is something to strive for and it is measurable when you have achieved it. It gives meaning to what the Scrum Team is working on.
The latest version of the Scrum Guide does not prescribe what the details of a Product Goal are, which means that the Scrum Teams can now form their goals for their context. For example, some Scrum Teams might work toward a Product Goal that is very aspirational and high level, another Scrum Team may have a quarterly Product Goal that is very focused. Determining the Product Goal depends on the context.
The desire to make Scrum more usable for different contexts and to double down on the transparency required in Scrum is what the motivation was behind the addition of the Product Goal. Naturally, Scrum Teams are formed for the purposes of pursuing something. Immaterial of the context, that is common to all Scrum Teams.
Adding a Product Goal makes that pursuit more explicit and makes the use of Scrum more attractive to teams that work in a complex environment. It also brings clarity in the connection between the Scrum Team, their work, and the context of the Product Goal. It is common to see a team so focused on what they are doing they forget the ultimate context. Product Goal can bring great clarity and allow work to be inspected in the context of the Product Goal.
More direct and clearer
It’s worth noting that the first documented version of the Scrum was more than 100 pages long. Over the years, it has grown and shrunk based on feedback and learning. Elements were added, elements were removed and elements were changed. However, it has been argued that the basics have never changed and all that we really need to remember is the simple idea behind Scrum which required an empowered team, focused on a problem, working empirically.
The most recent changes in the Scrum Guide framework do provide us with the ‘dance steps’ to make it real, but then again it is up to the Scrum teams to enhance it to meet their context.
