This article presents the author's view of what you need to reflect on and consider changing when using Scrum based on the November 2020 update to the Scrum Guide. It lists the changes and clarifications that affect each team or role defined in the Scrum Guide.
In November 2020, there was buzz around the update to the 2017 version of the Scrum Guide. How these changes could affect teams was on the minds of many. The intention of these changes was to simplify the document, make the guide less prescriptive, and be more generally applicable to any team in any organization [6]. The origins of these updates are founded on interactions between the Scrum Guide authors and its trainers over the past several years when discussing the Scrum Guide and its meaning for individuals, teams, and organizations.
This article presents my view of what you need to reflect on and consider changing when using Scrum based on this update. It lists the changes and clarifications that affect each team or role defined in the Scrum Guide. This information was compiled from various articles and a line by line comparison between the 2020 and 2017 versions of the Scrum Guide. In this article, there is a review of additions and changes, including significant rewrites that serve to clarify the intent that was present in previous versions of the Scrum Guide.
The Role of the Scrum Team
Smaller Is Better
For Scrum teams as a unit, there were a couple of changes and clarifications. The Scrum Guide now states that you should consider splitting Scrum teams that include more than 10 people. The quote from The Scrum Guide [5] is:
“The Scrum Team is small enough to remain nimble and large enough to complete significant work within a Sprint, typically 10 or fewer people. In general, we have found that smaller teams communicate better and are more productive. If Scrum Teams become too large, they should consider reorganizing into multiple cohesive Scrum Teams, each focused on the same product.”
Refine Based on Context
The guidance on the amount of effort spent on refinement activities was removed. The 2017 version mentioned that typically no more than 10 percent of the team’s capacity was used for refinement activities. This removal reflects the reality of the ebb and flow of required refinement when getting ready to work on a new goal or larger work stream, which allows the team to decide how much time to spend on refinement based on context. For example, when planning a new feature that is a major change to your product, the team may need to hold more sessions for a Sprint or two to get to a shared understanding of the need, possible options, sequence of work, architectural changes, etc. than for a feature that is well understood and already underway.
Whole Team Collaboration
The wording around what the Product Owner and a “Development Team” is responsible for was removed to emphasize the role of the entire team collaborating together during all Scrum events as needed. The Scrum Guide [5] now uses wording to reflect this:
“The Scrum Team is responsible for all product-related activities from stakeholder collaboration, verification, maintenance, operation, experimentation, research and development, and anything else that might be required. They are structured and empowered by the organization to manage their own work.”
“The entire Scrum Team is accountable for creating a valuable, useful Increment every Sprint.”
From the Sprint Review section: “During the event, the Scrum Team and stakeholders review what was accomplished in the Sprint and what has changed in their environment. Based on this information, attendees collaborate on what to do next.”
Self-Managing Teams
Scrum teams are also now described as self-managing rather than self-organizing. The team now decides both what is done and who does what. This adds responsibility to the Scrum Team, reinforces acting as a team to decide what is being done, and removes the premise that the Product Owner solely decides what is done with the team then and how it gets done. Self-management implies that the team adapts when new information is discovered and acts. The Scrum Guide [5] now uses wording to make this clear:
“They are also self-managing, meaning they internally decide who does what, when, and how.”
“Adaptation becomes more difficult when the people involved are not empowered or self-managing. A Scrum Team is expected to adapt the moment it learns anything new through inspection.”
Delivering More Value
The new Scrum Guide attempts to clarify the timing of the delivery value to account for the possibilities of today’s technology and way of working. There is a statement describing that there can be multiple increments per sprint; there is no need for the Scrum Team to wait until the end of the sprint to demonstrate value. The Scrum Guide [5] states:
“Multiple Increments may be created within a Sprint. The sum of the Increments is presented at the Sprint Review thus supporting empiricism. However, an Increment may be delivered to stakeholders prior to the end of the Sprint.”
Scrum Teams also need to focus on the purpose and description of the Definition of Done. New wording around commitment emphasizes a renewed focus on delivering capabilities that meet the needs of customers and the standards of the organization by the end of each Sprint. Before there was a statement regarding future improvements to create a higher level of quality and to be in usable condition. Usable does not imply the level of quality required to achieve the desired outcomes. The supporting Scrum Guide [5] wording to reinforce this intent includes:
“The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product.”
Finally, the Product Owner is not solely in charge of leading the Sprint Review, as the entire team is involved as they see fit. Many teams that I’ve been a part of have been operating this way for years already due to understanding the power of teams. The Scrum Guide [5] now says:
“During the event, the Scrum Team and stakeholders review what was accomplished in the Sprint and what has changed in their environment. Based on this information, attendees collaborate on what to do next.”
Role of Product Owners
Meeting Product Goals
The 2020 Scrum Guide has added language that the Product Owner is now responsible for developing and meeting a “Product Goal”. A Product Goal is the current view of the long-term objective that is represented in the Product Backlog, which may change over time as more is learned and validated. The Product Goal is not a stretch goal, is shaped by the desired business outcomes, and is driven by market conditions. The 2020 Scrum Guide update removes the word “vision” that it used in the 2017 version to describe that an increment achieves a vision or goal. The sole idea of what comes in the future is only described via either the Sprint Goal or Product Goal.
Your organization’s context will drive which characteristics of the definition of Product Goal works best. The Product Goal could be a higher-level statement similar to what some call a vision, a specific step that leads to a higher-level vision, described in more detail in a vision statement document or a business canvas, or whatever form best fits how your agile planning and execution works. See [7] and [2] for more detail of what a Product Goal is, and see [4] or [3] for examples of how Vision and Product Goal could relate to each other. With the Product Goal defined, the Scrum team can work on defining and refining what needs to be included in the Product Backlog that will result in fulfilling the Product Goal. The new Scrum Guide [5] supports this concept with the statements:
“Responsible for “Developing and explicitly communicating the Product Goal”
“The Product Goal is the long-term objective for the Scrum Team.”
“They must fulfill (or abandon) one objective before taking on the next.”
“An Increment is a concrete stepping stone toward the Product Goal.”
Product Owner Accountability
For the role of the Product Owner, there is clarification about acting as a team running ceremonies described earlier. The Product Owner is not solely in charge of leading the Sprint Review with a rewording that describes a unified team is running an effective inspect and adapt event.
The Product Owner is now accountable—not responsible—for managing the Product Backlog. The 2017 Scrum Guide stated that the Product Owner was the sole person responsible. This is related to the emphasis of working together as a collaborative Scrum Team in the new Scrum Guide [5] and is stated as:
“The Product Owner is also accountable for effective Product Backlog management…”
In my experience, when developers are more actively collaborating with the Product Owner in creating the Product Backlog, the more cohesive and effective the team becomes.
The Role of Developers
Developer as an Explicit Role
The use of “Development Team” was removed, and the word “Developer” is used to represent a team member with specific accountability. This is a reinforcement of collaboration of the entire team on planning and key decisions rather than parts of the team working in an adversarial way, such as a team within a team. The new Scrum Guide [5] describes this as:
“Scrum defines three specific accountabilities within the Scrum Team: the Developers, the Product Owner, and the Scrum Master.”
“Developers are the people in the Scrum Team that are committed to creating any aspect of a usable Increment each Sprint.”
Daily Scrum Flexibility
The three sample questions used for Daily Scrum were removed since they were believed to be limiting, and more important questions may be more valuable to discuss depending on context. The use of many other types of questions that could be more effective in specific contexts have been described by Scrum trainers, books, and other publications and are now common knowledge in the Scrum community. The supporting statement in the new Scrum Guide [5] is:
“The Developers can select whatever structure and techniques they want, as long as their Daily Scrum focuses on progress toward the Sprint Goal and produces an actionable plan for the next day of work.”
The 2020 Scrum Guide also makes their original intent clearer on when the team should meet to inspect and adapt. Developers meet whenever needed to adapt their plan towards meeting the sprint goal and not just immediately after Daily Scrum, which was mentioned as the typical case in the 2017 Scrum Guide. The new Scrum Guide [5] states:
“The Daily Scrum is not the only time Developers are allowed to adjust their plan. They often meet throughout the day for more detailed discussions about adapting or re-planning the rest of the Sprint’s work.”
The Role of Scrum Masters
Scrum Masters as Leaders
There were no changes that affect the role and responsibility of Scrum Master, although there were some significant clarifications. First, Scrum Masters are described as leaders who serve the Scrum Team and the larger organization not just servant leaders who help. They lead in creating positive change, take action, and are not always acting in a passive manner behind the scenes. Sometimes Scrum Masters act decisively to create change rather than solely trying to influence teams and their organization over time. The Scrum Master is accountable for the effectiveness of the team they help, and that responsibility sometimes requires action. These actions focus on driving improvement in the team’s practices and an understanding of how the Scrum framework works. Over the last few years, Scrum training sessions and publications have explored the concept of Scrum Masters not being passive bystanders. The examples that support this concept in the Scrum Guide [5] are:
“Scrum Masters are true leaders who serve the Scrum Team and the larger organization.”
“The Scrum Master is accountable for the Scrum Team’s effectiveness. They do this by enabling the Scrum Team to improve its practices, within the Scrum framework.”
The other change to describe the original intent of the Scrum Master role is that a Scrum Master causes the removal of impediments but are not necessarily the removers. The Scrum Guide now says “Causing the removal of impediments to the Scrum Team’s progress.”
References
[1] Geske, J. (n.d.) Scrum Guide Comparison.
https://amazing-outcomes.de/en/resources/downloads/comparison-scrum-guide-2020-and-scrum-guide-2017
[2] Lukassen, C. (2020, November 18). Product Goal.
https://www.scrum.org/resources/blog/product-goal
[3] Perri, M. (2016, July 14). What is Good Product Strategy?
https://melissaperri.com/blog/2016/07/14/what-is-good-product-strategy
[4] Pichler, R. (2020, December 1). OKRS in Product Management.
https://www.romanpichler.com/blog/okrs-in-product-management/
[5] Schwaber, K. & Sutherland, J. (2020, November). The Scrum Guide.
https://www.scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-US.pdf
[6] Sutherland, J., Sutherland, JJ., Schneier, A., etc. al (2020. December 4). 2020 Scrum Guide Changes and Updates Explained.
https://www.scruminc.com/2020-scrum-guide-changes-updates-explained/
[7] West, D. (2020, November 18). Scrum Guide 2020 Update - Introducing the Product Goal.
https://www.scrum.org/resources/blog/scrum-guide-2020-update-introducing-product-goal
