Happy Birthday Scrum!
Scrum celebrates 25 years with an updated 2020 Scrum Guide.
Scrum was first introduced in a paper at the 95 OOPSLA Business Object Design and Implementation Workshop by Ken Schwaber and Jeff Sutherland.
In 2010 Ken and Jeff published the 1st Scrum guide and since then they have updated it every couple of years. The latest version was released on November 18th, 2020. Let us take a deeper dive into the top 11 changes in the updated 2020 Scrum Guide along with an explanation of why the change was made and the impact this change will have.
1. A Minimally Sufficient Framework
This is not new. Scrum is a framework and not a process, technique, or definitive method. It is simple and lightweight instead of being overly prescriptive and detailed. This has always been the case and in this latest 2020 Scrum Guide update it is called out even further by highlighting that
“…The Scrum framework is purposefully incomplete, only defining the parts required to implement Scrum theory…”
Also, any language that was considered a little too prescriptive or detailed was removed and thus the guide shrunk from 18 pages down to 13 pages.
Many forget this point and keep asking for details of how to do x and what to do in situation y? And the answer is it depends based on your context. Use Scrum as your guide and through empiricism, uncover the effectiveness of the processes and techniques you are using within the framework and adjust them according to your team, your organization, and your environment. Do what works for you while staying true to the Agile values and principles and the spirit of Scrum.
2. One Scrum Team, 3 Accountabilities
The Scrum Team consists of a Product Owner, a ScrumMaster and Developers. Previously Developers were referred to as the Development Team, so we had a Development Team within the Scrum Team. This terminology was always awkward and confusing with many incorrectly referring to the Development Team as the Scrum Team and leaving the Scrum Master and Product Owner as outsiders to the team. It diminished the notion of one team working together collaboratively to deliver value and created a us vs. them behavior between the Developers and the Product Owner. The Developers felt they were working for the Product Owner as opposed to collaborating with the Product Owner.
The 2020 Scrum Guide addresses this misunderstanding by dropping the term development team and replacing it with just Developers. So, it’s just one Scrum Team and the Product Owner, the Scrum Master and the Developers are all part of the same one team. Developers in this context, like before, do not refer to just coders or programmers but to anyone working on product development activities. “…Within a Scrum Team, there are no sub-teams or hierarchies. It is a cohesive unit of professionals focused on one objective at a time, the Product Goal…”
Furthermore, the 2020 Scrum Guide clarifies that
“…The entire Scrum Team is accountable for creating a valuable, useful Increment every Sprint…”
and now identifies 3 accountabilities for the Scrum team:
- Developers accountable for delivering a working usable Increment each Sprint
- A Product Owner accountable for maximizing the value of the product resulting from the work of the Scrum Team
- A Scrum Master accountable for the Scrum Team’s effectiveness.
3. The Product Definition
Previous Scrum guides talk about Scrum being used to manage complex products. To clarify what is meant by products, the 2020 Scrum Guide adds a Product definition:
“…A product is a vehicle to deliver value. It has a clear boundary, known stakeholders, well-defined users or customers. A product could be a service, a physical product, or something more abstract…”
4. The Product Goal
Each Sprint, with the delivery of each Product increment, brings us a step closer and closer to a product vision or goal. However, many teams do not have a vision they are working towards and end up working on unrelated items without a specific focus or overall objective. To help clarify this anti-pattern, the 2020 Scrum Guide emphasizes working towards a product goal.
“…The Product Goal describes a future state of the product which can serve as a target for the Scrum Team to plan against. The Product Goal is in the Product Backlog. The rest of the Product Backlog emerges to define “what” will fulfill 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.”
The 2020 Scrum Guide clarifies that the Scrum Team starts with the Product Goal, and the Product Backlog emerges with Product Backlog Items that will fulfill that goal. In turn, the output of every Sprint is based on these Product Backlog Items which means each Product Increment helps us get closer to the goal. This creates necessary focus and ensures the work the team is doing is aligned to deliver on an overall vision. The Scrum Team makes a commitment towards the Product Goal as opposed to the Product Backlog Items.
5. The Sprint Goal
Unlike the Product Goal, the Sprint goal is not new. The Sprint Goal ensures the team is focused on working together collaboratively on a cohesive set of items as opposed to working individually in silos on unrelated items. The previous Scrum Guide talked about creating the Sprint Goal in part 1 of Sprint Planning (the What). However, many teams gloss over that and fail to come up with Sprint goals to help them build product increments that bring them closer to their product vision.
To help correct this anti-pattern, the 2020 Scrum Guide emphasizes and elevates the need for a Sprint Goal and ties it to the Product Goal. Each Sprint goal is tied to the overall Product Goal and goes in the Sprint Backlog. Sprint Planning is now three parts instead of two and starts out with the Why or the Sprint Goal (topic 1), followed by the What or the Product Backlog Items that will help accomplish the Sprint Goal (topic 2) and then the How or the tasks that the team needs to complete to accomplish the Sprint Goal (topic 3). The team makes a commitment to accomplishing the Sprint Goal as opposed to the items in the Sprint Backlog. In their Daily Scrums, the focus is on progress made towards achieving the Sprint Goal as opposed to the individual status of items.
“…The Sprint Goal is the single objective for the Sprint. Although the Sprint Goal is a commitment by the Developers, it provides flexibility in terms of the exact work needed to achieve it. The Sprint Goal also creates coherence and focus, encouraging the Scrum Team to work together rather than on separate initiatives…”
“…Topic One: Why is this Sprint valuable: The Product Owner proposes how the product could increase its value and utility in the current Sprint. The whole Scrum Team then collaborates to define a Sprint Goal that communicates why the Sprint is valuable to stakeholders. The Sprint Goal must be finalized prior to the end of Sprint Planning…”
6. The Definition of Done
Like the Sprint Goal, the Definition of Done is nothing new. However, many teams fail to create and improve on their Definition of Done. The 2020 Scrum Guide elevates and emphasizes the need for a Definition of Done and is a commitment to the Product Increment. It emphasizes that the Product Increment must meet a certain level of quality as defined by the Definition of Done.
“…Work cannot be considered part of an Increment unless it meets the Definition of Done.…The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product…”
7. Decoupling the Sprint Review from the Product Increment
At the end of every Sprint, the team must deliver a Product Increment that meets the Definition of Done. Again, this is nothing new. The increment is inspected in the Sprint Review to ensure the team is on the right track and to determine what to work on next. However, there is nothing preventing the team from delivering Product Increments sooner. Yet, some teams even struggle with delivering a quality working increment just at the end of the Sprint. This is typically due to a lack of Agile Engineering practices as well as a failure to properly refine the Product Backlog Items into smaller more manageable valuable vertical slices. Working on larger items increases the risk of reaching the end of the Sprint without a working Product Increment.
To help with this, the 2020 Scrum Guide encourages working with smaller batches and calls out continuously delivering value to stakeholder, not just at the end of the Sprint. This aligns nicely with the concept of continuous deployment and continuous delivery.
“…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. The Sprint Review should never be considered a gate to releasing value…”
8. The Sprint Review as a Working Session
Once again, this is nothing new, but an important clarification. At the end of every Sprint, the Scrum Team holds a Sprint Review to collaborate with the stakeholders on what to do next by inspecting the Product Increment and adapting the Product Backlog. The Sprint Review was always intended to be an informal event about eliciting feedback and fostering collaboration. Many organizations incorrectly refer to the Sprint Review as a demo and limit it to a presentation by the Developers to the Product Owner with little to no input or discussions from stakeholders. Others incorrectly treat it as a gate to releasing value. To help correct these anti-patterns, the 2020 Scrum Guide clarifies that
“…The Scrum Team presents the results of their work to key stakeholders and progress toward the Product Goal is discussed…The Sprint Review is a working session and the Scrum Team should avoid limiting it to a presentation… The Sprint Review should never be considered a gate to releasing value…”
9. A Self-managing Scrum Team
Previous Scrum Guides referred to the Scrum Development team as self-organizing, meaning the Developers decide amongst themselves the tasks needed to accomplish the work and who will work on them to build a product increment and accomplish the Sprint Goal. So, the development team determines the who and how while the Product Owner determines the what based on the ordering of the Product Backlog.
The difference between self-managing and self-organizing is around the what. With self-organizing teams, someone else determines the what while the team determines the how and who. With self-managing teams, the team owns the how, who, as well as the what.
In the 2020 Scrum Guide, there is an emphasis on the one team terminology that includes the 3 accountabilities of the Product Owner, the Scrum Master, and the Development Team. So, the Scrum Team is better described as self-managing since the Product Owner is part of the team that determines what to work on. So now the Scrum Team determines what to work on, how to do it, and who will accomplish it.
“…Scrum Teams…are also self-managing, meaning they internally decide who does what, when, and how…”
10. Word on Scaling
Previous Scrum Guides mentioned that if multiple teams are working on the same product, one Product Backlog is used. However, when scaling, most organizations end up creating multiple Product Backlogs for each team, and each with its own Product Owner. This leads to lack of alignment, conflict of interests, and finger pointing as Product Owners try to optimize their own backlog and lose focus of the bigger picture. Accountabilities, responsibilities, and ownership become unclear and muddied.
The 2020 Scrum Guide tries to address this anti-pattern by going further and clarifying that all the developers are working with just one Product Owner on one Product Goal. This ensures that everyone is working on the most valuable items to help accomplish the Product Goal instead of focusing on Product Backlog items that might seem high priority from the perspective of their local team Product Backlog but are actually low priority for the overall bigger picture.
“…If Scrum Teams become too large, they should consider reorganizing into multiple cohesive Scrum Teams, each focused on the same product. Therefore, they should share the same Product Goal, Product Backlog, and Product Owner…”
11. The Scrum Master as a True Leader
The 2020 Scrum Guide introduces the term true leader.
“…Scrum Masters are true leaders who serve the Scrum Team and the larger organization…”
I think all the 2020 Scrum Guide updates mentioned so far are a move in the right direction that help clarify common Scrum misconceptions. This one however I am not so sure about, mainly because I don’t think the term true leader makes things any clearer.
Previously Guides referred to the Scrum Master as a servant-leader. The term servant-leader was coined back in the 70s and there has been a lot of papers and books published on the topic. However, many organizations are still unfamiliar with servant-leadership and had Scrum Masters be team administrators, facilitators, or just note takers with little to no leadership experience. Scrum Masters are change agents that lead the Scrum adoption in organizations, help stakeholders understand and use empiricism for complex product development, foster self-organization, self-management, cross-functionality, and empowerment, help remove impediments, help the Scrum Team focus on creating high value and high quality Product Increments, and focuses on continuous improvement.
To help clarify this misconception, the 2020 Scrum Guide dropped the term servant-leader and instead replaced it with a true leader that serves the Scrum Team and the organization and is accountable for the Scrum Team’s effectiveness. Hopefully this change in terminology will bring back an emphasis on the leadership aspect of the ScrumMaster.
What Else?
There are other more subtle changes to the Guide. However, these 11 updates to the 2020 Scrum Guide are the ones that I hope will help provide more clarity on many misconceptions that are out there. For teams and organizations doing Scrum well, the changes in the 2020 Scrum Guide will have little to no impact. For others that are struggling with their adoption, hopefully the clarifications in the updated 2020 Scrum Guide might highlight few anti-patterns and guide them in correcting them to get the most benefits out of Scrum.
