Scrum Guide is the official resource to understand the Scrum framework and its corresponding rules. Usually, every 2 to 3 years a new version of Scrum Guide will be released by the creators of Scrum – Ken Schwaber and Jeff Sutherland. The Lates version is Scrum Guide 2020, which was released in November 2020. The previous version was Scrum Guide 2017, which was released in November 2017. In this article, we shall clearly see in detail the various changes that were made in the Scrum Guide 2020 and its differences with the Scrum Guide 2017 version, and the possible reason for implementing those changes.
|
Change Description |
Scrum Guide 2017 Version | Scrum Guide 2020 Version |
Possible Reason for change |
| Length of Scrum guide (Number of pages) | 19 Pages | 14 Pages | The authors have removed some content that looked more prescriptive. So, the reason behind page count reduction is to make Scrum an even more effective “framework” rather than a “prescriptive” methodology. 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. |
| Definition | A 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. | A 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 the “adaptive solutions” the definition is changed. |
| Definition | It 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 providing the 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 the incompleteness of the Scrum framework. This helps people to have the responsibility to identify correct practices, processes, tools, etc. It also focuses on “people” involvement that uses the Scrum framework. |
| Scrum Theory | Not mentioned about Lean | Scrum is founded on empiricism and lean thinking | Scrum focuses on “eliminating waste” which is the primary philosophy of Lean. In the latest version, this was explicity mentioned. |
| Empiricism definition | Empiricism asserts that knowledge comes from experience and making decisions based on what is known | Empiricism asserts that knowledge comes from experience and making decisions based on what is observed. | A complex problem, where the unknown is more than known, Solutions cannot be attained in a single attempt and multiple experiments may be needed to tackle the problem. So the solution may evolve after several experiments. Every experiment provides some learning. Hence, the word “observed” is much more appropriate than “Known” |
| Roles | To represent the Scrum team the term “Roles” was used | “Roles” was replaced with “Accountabilities” | 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, rather than ownership of end result of those responsibilities. Replacing Role with Accountability implies the emphasis on ownership that the Scrum team should have on the end result. |
| Development Team | This was used as part of the Scrum Team | This is renamed as “Developers” | Development Team or Scrum Team terms are more associated with IT software industry. In order to emphasize that Scrum is a framework that can be used in any industry where people develop in increments to create value to customers, Scrum Team was renamed to “Developers”. |
| Team size | Development Team size should be between 3 and 9 | The 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 Teams | It was not explicitly mentioned how to handle | It is clearly mentioned about splitting large Scrum teams into smaller | This helps in clearly understand how to form small Scrum Teams to work on a larger project without compromising on Transparency and effective communication. |
| Self-organizing | This was used for the Development Team should be self-organized | This is changed to self-managed and mentioned at the Scrum Team level | Self-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 hierarchies | It is to emphasize the Scrum Team as “one Team”. |
| Product Owner Responsibilities | It was mentioned that some of the responsibilities can be delegated to Development Team | Some of the Product Owner responsibilities can be delegated to others (not only Developers) | To whom some PO responsibilities can e delegated depends on the industry. Sometimes it may be some subject matter experts to whom some of the Product Owner’s responsibilities can be delegated. However, it is clearly mentioned that the Product Owner is still accountable. |
| Scrum Master Responsibilities | Responsibility: Establishing Scrum | Accountability: Establishing Scrum and Scrum Team’s effectiveness | It 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 Organization | Apart from the Services to the Product Owner separately, some services are listed under the Scrum Team level. |
| Servant Leader | It was mentioned as Scrum Master should be a “Servant Leader” | It is changed to “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 role but is a Leadership role with organization-level responsibility. |
| Events | It was mentioned “Same time, Same place” only for the Daily Scrum | “Same time, Same place” is now applied for all the events within Sprint | For 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 the same locations so the Transparency can be high and those artifacts can be effectively used during these events. |
| Sprint | It was not clearly mentioned that it is a container of all other four events | It is now made clear that Sprint is a container event that 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 invitees | It was mentioned that any others can attend based on an invitation from Development Team | Scrum Team can invite any other people to provide advice | The 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 a high level of collaboration with one direction |
| Daily Scrum | It was mentioned about 3 questions to be covered in Daily Scrum. | It is made very clear that the Developers can decide the suitable Structure | This 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 Scrum | It 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 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 contribute as Developers always. |
| Meeting after the Daily Scrum | It was mentioned that the Development Team can meet immediately after the Daily Scrum | It is mentioned that the Developers can meet throughout the day for more detailed discussions and re-planning | Depending 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 Retrospective | It 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 Backlog | The 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 Refinement | Usually should not take more than 10% of the Development Team capacity in the Sprint | This was replaced with “as needed”. | 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 Goal | Not mentioned in this version | It 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. A goal helps them to visualize the future of the Product and plan accordingly. |
| Artifact Commitment | Not 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 |
| Increment | One increment by the end of the Sprint | There can be more than one increment created throughout the Sprint | It makes it clear about continuous value delivery based on the customer needs |
| Increment inception | Not clearly specified | The 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 Review | Not clearly mentioned | Explicitly mentioned that an increment can be released before Sprint Review | This improves the speed of continuous delivery and frequent value creation to Stakeholders |
| Definition of Done | Created By Development Team | Created by Scrum Team | It will be more clear in terms of common understanding on the criteria for “Done” among Scrum Team |