Scrum Guide 2020 vs. 2017: what’s new?

The recent Scrum Guide update echoed widely among people working in agile, primarily because it was the first change in 3 years. The second surprise was the fact that the Guide was not expanded, but shortened by the whole 6 pages. How spectacular are these changes? Will Scrum still remain Scrum? We compared Scrum Guide 2017 with Scrum Guide 2020. In this article, we present the most important differences.

What changes Scrum Guide 2020 includes? Practitioners of the agile methodology can sleep peacefully – the novelty will not turn their working life upside down. Most of the changes are simply a clarification of existing definitions. The most important changes focused on four areas of the team, roles, meetings and work planning.

In 2017, the project team consisted of the Scrum Team and the Development Team, which was treated as a sub-team. The Scrum Team was cross-functional and self-organizing, and the Development Team was cross-functional, self-organizing, without tiles or sub-teams. This way, unnecessary hierarchy was created, and there was also a danger of shifting responsibility. The Scrum Team sometimes functioned as a unit not directly involved in Sprints, and value generation fell solely on the Developer’s shoulders. Scrum Guide 2020 eliminates this problem by defining the Scrum and Development Team as a single unit, without dividing them into sub-teams. From now, the fundamental unit of Scrum is the Scrum Team, that is cross-functional, self-managing, and without sub-teams or hierarchies.

The Scrum Team in the new release has one common goal, which can only be achieved through close cooperation of its members. As a result of this change, the term “Development Team” has been replaced by the word “Developers”. Finally, the Scrum Team consists of Developers, a Scrum Master, and a Product Owner. This way, theyreduced the potential for dysfunctions between the Product Owner and the Development Team. Moreover, recommended team size has been changed from 3-9 members to 10 or fewer. It allowed us to see the Scrum Team more as a cohesive unit and reduced the risk of dysfunctions between accountabilities.

The Scrum Team has so far been called a self-organized team. The concept of self-organization meant the autonomy of team members, within which they could decide on team composition, responsibilities, or working conditions. In addition, this concept could refer to any team, not just in the context of Scrum. That’s why the term “self-organizing” has been replaced by “self-managing”. The Scrum Team decides who does what, when, and how, so it self-manages its work. In this case, management means ensuring that the work is done efficiently.

Before the Scrum Guide changes, the main responsibility of the Scrum Team was incremental delivery of “Done” products. Now, the Scrum Team as a cohesive unit is responsible for all product-related activities and creating a valuable, useful Increment every Sprint. To sum up – the Scrum Team is fully accountable for its results as a whole.

Let’s make it clear – Scrum is not about roles, it consists of people. You don’t play the role of Scrum Master or Product Owner, you ARE the Scrum Master or Product Owner. Only this approach ensures a proper commencement of responsibility without flipping it. Responsibility allows you to take actions that will have a real impact on the team’s efficiency gains, rather than rigidly limiting it to a textbook definition of role and activity. That’s why currently used term “roles” has been replaced by “accountabilities”.

This clarification also helps to see the Scrum Team as something more than just a cohesive unit – as a product team. That makes the whole Team responsible for Incrementation and effectiveness, and thinking about the Team, we include not only Developers, but also the Scrum Master and the Product Owner.

The Product Owner is now more flexible in delegating responsibilities. They used to be delegated to the Development Team, and now, according to Scrum Guide 2020, the Product Owner may delegate responsibilities to others. In 2017 the Scrum Master was accountable for establishing Scrum. After the Scrum Guide 2020 release, thegoals of the Scrum Master have been reinforced to establish the Scrum Team’s effectiveness.

Agile precursor in Poland, Kate Hobler, explained the difference between role and accountability in a publication on linkedIn.

Another huge change was in the area of meetings. Since 2020, criteria of all events that are held at the same time and place should be unified. Previously, this only involved the Daily Scrum. In the 2017 version of the guide, meetings after Daily Scrum were unspecified, but now it has been clarified that Developers often meet throughout the day.

Moreover, the Sprint Planning invitees should be invited by the Scrum Team, instead of the Development Team. Earlier, Sprint Review Stakeholders were invited by the Product Owner. In Scrum Guide 2020, it’s not prescribed who invites them. The Scrum Team decides who does what, when, and how. This highlights the unity of the Scrum Team as a whole.

Sprint Planning Topics have also changed. Since 2020, the Scrum Team should discuss the value and make it transparent by discussing not only what and how but also why. The next change was sprint review demo and steps. So far, the process has been as follows:

Now the Scrum Team presents and then Attendees collaborate on what to do next. As it was highlighted earlier, the whole Scrum Team decides who does what, when, and how.

Also, the improvements from Retro have changed a bit. Previously, the Sprint Backlog contained at least one process improvement. The Scrum Guide 2020 clarified that the Sprint Backlog may contain process improvements. This suggestion allows other methods, like Lean or Kanban, to follow-up impediments.

Scrum Guide 2020 brought some improvements in the area of work management. Redefinition of Sprint Backlog, Increments, and Artifact Commitments made Scrum not only more flexible, but also described its goals precisely. The teams shouldn’t do agile just for doing agile, but they should keep in mind that achieving the Sprint Goal is the aim of all taken actions. The work is efficient only when it brings real value.

Also, the definition of Sprint Backlog changed itself. Sprint Backlog elements in 2017 was the set of Product Backlog items selected for the Sprint (what), and an actionable plan for delivering the Increment (how). The creators of Scrum Guide 2020 decided it was necessary to discuss the value and make it transparent. As a result, the Sprint Backlog consists of:

Some other changes and definitions have been clarified by Scrum Guide 2020. Refinement is no longer limited to less than 10% of the Development Team capacity but should consume as much time as needed as long the capacity used doesn’t endanger the Sprint Goal. The Product Goal wasn’t required, but now it’s a commitment of the Product Backlog. This approach allows the team to discuss the value and unifies the Scrum Team as the Product Team.

Artifact Commitments consisted of monitoring progress toward goals, monitoring Sprint progress, and the Definition of Done was the artifact of transparency. This approach has been replaced by following commitments:

It unifies the Scrum Team as a Product Team with clear goals.

Let’s put it straight – nothing was clear before the Scrum Guide 2020 when it comes to the topic of increments. From now, there can be one or multiple increments per Sprint. The release before the Sprint Review is also explicitly allowed. According to Kanban Guide for Scrum Teams: “It’s a common misconception that teams can only deliver value once per Sprint.” The birth of Increment also was not specified – now a Product Backlog Increment meets Definition of Done. The Definition of Done is not defined only by the Development Team but by the whole Scrum Team. Moreover, the Scrum Team should be focused on value. The term “potentially releasable Increment” has been replaced by “valuable, usable Increment”. In this approach, it is still not required to release the Increment, but it can be done this way.

Scrum Guide hasn’t change a lot. It is much clearer, full of clarifications, and shorter than ever before. The fundamentals of Agile didn’t change, but it was highlighted that the Scrum Team is cohesive, unified, and all of the team members are responsible for Sprint efficiency. The accountabilities are not a description of roles, but they mean rather the specific approach. Treating Agile more flexible is fully accepted and approved as long as it helps bringing the real value and doesn’t have negative impact on Sprint success. In our opinion, the most important changes are those listed below:

Agile should be agile. It is a work management tool that adapts to the work style of individual teams thanks to its flexibility. It is worth knowing this methodology, because the implementation of even its elements can significantly increase the quality, comfort and efficiency of work. Finally, we should remember that the main purpose of agile practices by the team is to bring value to the stakeholders.

Read more about Agile practices on the Deviniti blog:

Tired of reading? Listen to our podcast about useful Agile practices outside of software teams and IT industry.