Scrum Guide is the official resource to understand the Scrum framework elements and corresponding rules. The good thing is, Scrum Guide also will be inspected and adapted time to time to make it even effective. Usually every 2 to 3 years a new version of Scrum Guide will be released by it’s co-creators Ken Shwaber and Jeff Sutherland. Recently, in November 2020, the latest version (2020 version) Scrum Guide was released. Prior to that was November 2017. Based on the information received from various industries, organizations that implement Scrum, the changes will be done to Scrum Guide.

In this article you will clearly be able to understand the changes between 2017 and 2020 versions of Scrum Guide along with the reasons behind those changes.

Change Description2017 Version2020 VersionPossible Reason
Length of Scrum guide (# of pages)19 Pages14 PagesIn order to make it less prescriptive. Authors have removed some content that looked prescriptive. So the reason behind page count reduction is to make it even more effective “framework” rather than a “prescriptive” methodology type. This means people who use the Scrum Guide will have even more responsibility to identify suitable tools, techniques, processes, and accountability to change them if they do not work.
DefinitionA framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems.Complex problem means, unknown is more than known. So for complex problems most of the time you may not have the first right solution, and you have to experiment. So to highlight on the “adaptive solutions” the definition is changed.
DefinitionIt was not explicitly mentioned about “incomplete”The Scrum framework is purposefully incomplete, only defining the parts required to implement Scrum theory. Scrum is built upon by the collective intelligence of the people using it. Rather than provide people with detailed instructions, the rules of Scrum guide their relationships and interactions.To make it clear about the framework, it was made clear by emphasizing on the incomplete way of the Scrum framework. This helps people to have responsibility to identify correct practices, processes, tools etc. It also focuses on “people” involvement that use the Scrum framework.
Scrum TheoryNot mentioned about LeanScrum is founded on empiricism and lean thinkingScrum anyway focuses on “eliminating waste” which is the primary philosophy of Lean. Now it is made it more clear about Lean thinking.
Empiricism definitionEmpiricism asserts that knowledge comes from experience and making decisions based on what is knownEmpiricism asserts that knowledge comes from experience and making decisions based on what is observed.A complex problem, where unknown is more than known. So the solution cannot be at single attempt and also many experiments may be needed to tackle the problem. So the solution can be evolved based on several experiments. Every experiment provides some learning. Hence, the word “observed” is much more appropriate than “Known”
RolesTo represent Scrum team the term “Roles” was used“Roles” was replaced with “Accountabilities”In general, people may confuse between Role and a Title. And, a Role can be played by many people and a role may come along with a set of responsibilities and people playing those roles will only focus on dealing with the responsibilities attached to that role but not on the ownership of end result of those responsibilities. Hence, converting the Role to Accountability brings more emphasis on making people aware of their accountability of the results in the Scrum Team.
Development TeamThis was used as part of Scrum TeamThis is renamed as “Developers”“Development Team” is closer to software, however Scrum can be used in any industry. So to represent the people who develop increments to create value to customers it is renamed to “Developers”.
Team sizeDevelopment Team size should be between 3 and 9The team size was moved to Scrum Team level instead of Developers. Now the Scrum Team size is not more than 10.It was sounding that the Development Team was separate when the size was mentioned at the Development Team level. To make it at a Scrum Team level the team size is moved to the Scrum Team level.
Large Scrum TeamsIt was not explicitly mentioned how to handleIt is clearly mentioned about splitting large Scrum teams into smallerThis helps in clearly understand how to form small Scrum Teams to work on a larger project without compromising on the Transparency and effective communication.
Self-organizingThis was used for the Development Team should be self-organizedThis is changed to self-managed and mentioned at the Scrum Team levelSelf-organizing means people who take care of who, when and how but the “what” is beyond them.
Self-managing means the team decides who does what, when and how. In order to make Scrum Teams more autonomous and accountable this change was made.
Team Skills

Scrum Team: cross-functional, self-organizing

Development Team: Cross-functional, Self-organizing, No other titles, No sub teams

Scrum Team: Cross-functional, Self-managing, No sub teams, No hierarchiesIt is to emphasize the Scrum Team as “one Team”.
Product Owner ResponsibilitiesIt was mentioned that some of the responsibilities can be delegated to Development TeamSome of the Product Owner responsibilities can be delegated to others (not only Developers)Depending on the industry in which the Scrum is implemented, sometimes it may be some subject matter experts to whom some of the Product Owner responsibilities can be delegated to. However it was clearly mentioned that the Product Owner is still accountable.
Scrum Master ResponsibilitiesResponsibility: Establishing ScrumAccountability: Establishing Scrum and Scrum Team’s effectivenessIt is to make it clear that Scrum Master should help Scrum Team in terms of improving collaboration, communication, practices, tools and so on which will improve the effectiveness of Scrum Team
Scrum Master Services

The Services were categorized into:

Product Owner, Development Team and Organization

The Services are categorized into: Product Owner, Scrum Team and OrganizationIt may be the case sometimes Product Owner and the Developers together to be coached to improve their collaboration, communication and the effectiveness of the Scrum Team as a whole. So apart from the Services to the Product Owner separately, some services are listed under the Scrum Team level.
Servant LeaderIt was mentioned as Scrum Master should be a “Servant Leader”It is changed to “True Leader”To avoid the misuse of Servant Leader it is replaced with True Leader. Servant Leadership is a part of “True Leader” skills. It is also to make it clear that the Scrum Master is not a team level but it is a Leadership role with organization level responsibility.
EventsIt was mentioned “Same time, Same place” only for the Daily Scrum“Same time, Same place” is now applied for all the events within SprintFor some projects like hardware/infrastructure, there may be some physical artifacts kept in the place of these events conducted. So, it will be effective to have these events at same locations so the Transparency can be high and those artifacts can be effectively used during these events.
SprintIt was not clearly mentioned that it is a container of all other four eventsIt is now made clear that Sprint is a container event which contains the remaining four events.It gives clarity about Sprint is a stand-alone unit in which the remaining four events will be done to create a useful and usable increment
Sprint Planning inviteesIt was mentioned that any others can attend based on invitation from Development TeamScrum Team can invite any other people to provide adviceThe advice can be anything related to functional advice, technical advice or any input related to practice and practices. Hence the Scrum Team can invite related other people to Sprint Planning
Sprint Planning Topics“What” and “How” topics were listed in Sprint Planning“Why” topic is also added as an additional topic.It is important to know “Why” the current Sprint increment is being built so that Developers can work with unity and high level of collaboration with one direction
Daily ScrumIt was mentioned about 3 questions to be covered in Daily Scrum.It is made very clear that the Developers can decide the suitable StructureThis is to make it less prescriptive and leaves the responsibility of deciding the way the Daily Scrum has to be conducted to the Developers
Scrum Master and Product Owner role in Daily ScrumIt was mentioned the Development Team is responsible to have the Daily Scrum

It is mentioned as:

If the Product Owner or Scrum Master are actively working on items in the Sprint Backlog, they participate as Developers.

Depending on the Team size and the industry in which the Scrum is implemented, there may be a possibility of having Scrum Master and Product Owner to work on Sprint Backlog items. Hence this statement is included. It should not be considered that it is the best practice to have Product Owner and Scrum Master to contribute as Developers always.
Meeting after the Daily ScrumIt was mentioned that the Development Team can meet immediately after the Daily ScrumIt is mentioned that the Developers can meet throughout the day for more detailed discussions and re-planningDepending on the need (example to discuss resolution of impediments, any unplanned leaves based impact on the Sprint work, or assigning the work among within the Developers), it is good to have discussions throughout the day
Sprint Review

There was a script provided on who does what in Sprint Review which made it very prescriptive.

It was mentioned about invitees who have been invited by the Product Owner.

It was cut down by removing the step by step explanation.

It was not explicitly mentioned about who invites the attendees.

It is to make it less prescriptive and let the Scrum Team to decide how best the Sprint Review can be done to make it more effective.
Sprint RetrospectiveIt was not mentioned explicitly to add the improvements identified in Retrospective to the Sprint Backlog

It was mentioned:

“. They may even be added to the Sprint Backlog for the next Sprint.”

This is to remind the Developers during the next Sprint to work on the identified improvements.
Sprint BacklogThe Sprint Backlog is the set of Product Backlog items selected for the Sprint, plus a plan for delivering the product Increment and realizing the Sprint Goal.The Sprint Backlog is composed of the Sprint Goal (why), the set of Product Backlog items selected for the Sprint (what), as well as an actionable plan for delivering the Increment (how).It is to emphasize on the “Why” we are doing “what” we are doing in the Sprint. So adding Sprint Goal to the Sprint Backlog will provide clear direction to the Developers.
Product Backlog RefinementUsually should not take more than 10% of Development Team capacity in the SprintThis was replaced with “as needed”.By providing 10% sounds like a prescriptive way. Depending on the type of Product, Industry in which Scrum is implemented, the Scrum Team can decide the duration required for Product Backlog Refinement.
Product GoalNot mentioned in this versionIt was mentioned and will be part of the Product Backlog.Having a Product Goal helps to focus the efforts of the Scrum team more effectively. Goal helps them to visualise the future of the Product and plan accordingly.
Artifact CommitmentNot mentioned

There is clear commitment created for the three artifacts as below:

Product Backlog → Product Goal

Sprint Backlog → Sprint Goal

Product Increment → Definition of Done

Creating the commitment to each artifact will provide clarity to the Scrum Team on the direction and focus on the inspection of the work accordingly
IncrementOne increment by the end of the SprintThere can be more than one increments created throughout the SprintIt makes it clear about continuous value delivery based on the customer needs
Increment inceptionNot clearly specifiedThe moment a Product Backlog item meets the Definition of Done, an Increment is born.It is possible that an individual item in Sprint Backlog may create a standalone value to the stakeholders so it can be released independently as soon as it is done
Release of Increment before Sprint ReviewNot clearly mentionedExplicitly mentioned that an increment can be released before Sprint ReviewThis improves the speed of continuous delivery and frequent value creation to Stakeholders
Definition of DoneCreated By Development TeamCreated by Scrum TeamIt will be more clear in terms of common understanding on the criteria for “Done” among Scrum Team
    

Important note: The Scrum framework, as outlined in Scrum Guide, is immutable. While implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices.

Hence, please understand the insights of the Scrum Guide and accordingly implement suitable practices, tools, processes and techniques.

If you are a Scrum practitioner (Scrum Master, Product Owner, Developer or Agile Coach) it is always good to get your knowledge updated with the latest Scrum Guide version. It helps you to keep your knowledge up-to-date so that you can implement Scrum effectively with that knowledge.

So, keep updating your Scrum knowledge continuously and inspect and adapt.