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 Description | 2017 Version | 2020 Version | Possible Reason |
Length of Scrum guide (# of pages) | 19 Pages | 14 Pages | In 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. |
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. | 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. |
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 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 Theory | Not mentioned about Lean | Scrum is founded on empiricism and lean thinking | Scrum anyway focuses on “eliminating waste” which is the primary philosophy of Lean. Now it is made it more clear about Lean thinking. |
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 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” |
Roles | To 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 Team | This was used as part of Scrum Team | This 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 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 the 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) | 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 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 | It 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 Leader | It 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. |
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 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 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 invitees | It was mentioned that any others can attend based on 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 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 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 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 Development Team capacity in the Sprint | This 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 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. Goal helps them to visualise 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 increments 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 |
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.
The Scrum Guide is the primary source for understanding the Scrum framework and its rules. It gets revised every 3 to 4 years and the latest version of Scrum guide is November 2020. The revisions help the Guide evolve to remain effective and relevant. For those looking to deepen their knowledge and stay current, pursuing a CSM course online in Hyderabad or finding the best CSPO training institute in Hyderabad can be invaluable. Similarly, the best agile scrum training institute in Hyderabad offers comprehensive training to master the latest Scrum practices. This continuous learning helps professionals adapt to changes in Scrum, ensuring they can implement the framework effectively in their organizations.
Recent Posts
- What is Scrumban 16/10/2024
- Scrum Vs Kanban 16/10/2024
- Scrum Vs Extreme Programming (XP) 16/10/2024
- “Follow the Leader” Strategy in Product Development? 16/10/2024
- Blue Ocean and Red Ocean Strategies in Product Development? 16/10/2024