The refined Scrum Guide 2020 – launched on November 18 – includes some small, yet significant changes. The co-creators, Dr. Jeff Sutherland and Ken Schwaber, highlight the changes mentioned below from 2017 to 2020.
Our perspective on the updated Scrum Guide
Overall, we welcome the changes. We believe they take the guide back to its roots of being not too prescriptive and a real framework. This also results in the guide being easier applicable to industries outside of software development. There are some further changes we would like to see… but who knows what the next iteration will bring.
Changes from 2017 Scrum Guide to 2020 Scrum Guide
Next we will describe the changes between the Scrum Guide 2020 and previous versions. We will rate all changes as Scrum Academy an agile Training Provider.
Even Less Prescriptive
Over the years, the Scrum Guide started getting a bit more prescriptive. The 2020 version aimed to bring Scrum back to being a minimally sufficient framework by removing or softening prescriptive language. e.g. removed Daily Scrum questions, soften language around PBI attributes, soften language around retro items in Sprint Backlog, shortened Sprint cancellation section, and more.
Scrum Academy perspective:We like this change as this is a move back to being a framework rather than a body of knowledge (BoK) similar to the PMBOK® from PMI. The beauty of Scrum lies in its simplicity and universality. We have applied Scrum in software, hardware, pharma, and all types of services. A move back to the roots, makes the concepts more tangible for people outside of the software development world.
One Team, Focused on One Product
The goal was to eliminate the concept of a separate team within a team that has led to “proxy” or “us and them” behavior between the Product Owner and Dev Team. There is now just one Scrum Team focused on the same objective, with three different sets of accountabilities: Product Owner, Scrum Master, and Developers.
Scrum Academy perspective:
We love this change. The concept of a team within the team regularly resulted in confusion – be it in a training or later during implementation. The “us” vs. “them” mentality is really dangerous for any team and agile teams in particular. Still, there is an emphasis that accountabilities in the teams are clearly assigned.
We also like the emphasis that there are no formal hierarchies within the Scrum Team – just different accountabilities. We truly hope this small, yet important change in terminology will result in more and more people interpreting the roles in Scrum similar to us.
The one thing we would like to see change going forward is the name “Developers”. Too often do we see people assuming this means Software Developers – which is not the case.
Introduction of Product Goal
The 2020 Scrum Guide introduces the concept of a Product Goal to provide focus for the Scrum Team toward a larger valuable objective. Each Sprint should bring the product closer to the overall Product Goal.
Scrum Academy perspective:
In general, we like the introduction of the Product Goal and the emphasis that every sprint should bring the product closer to the overall Product Goal. But to be honest, we would have preferred the term Product Vision as this is a term many people have been using in the past. There are even tools build around this e.g. the Product Vision Board from Roman Pichler.
One aspect that we find helpful to add is a systematic approach to think about the Product Goal i.e. what does the Product Goal need to cover. At the same time, this could make the framework again too prescriptive… so maybe it is ok to keep it the way it is now.
In order to help teams systematically create a great Product Goal, we have created the Product Goal Canvas – see below. This simple tool helps teams to systematically think and create the Product Goal. You can learn more about how to use the Product Goal Canvas here.