What the new Scrum Guide 2020 means for our daily job!
On the 18th of November 2020, a new revision of the Scrum Guide was released and this time, the changes were massive compared to previous adaptations.
The new Scrum Guide 2020 includes the streamlining and modernisation of some concepts and sections as well as the elimination of convoluted terms and rigid guidelines. The objective of the changes is clear to me: less rules mean more freedom for a Scrum team to experiment with its processes, and more “Inspect and adapt”. It’s no longer about ticking boxes; it is more about the Scrum team achieving a common goal.
The new Scrum Guide simplifies much of the complexity that originally came from software development. Scrum 2020 is more inclusive and will work better for teams that do not come from software, such as marketing, sales or hardware teams.
Let’s have a detailed look at what changed and how it may impact our daily work. Please note that I will cover the changes in the Scrum Master role in a dedicated article.
Removing the Development Team
The abolition of the dev team seems at first sight to be a fundamental change; but it seems to me that this change should have the least impact.
Nevertheless, it took me some time to understand this change: Why of all things is the development team, the heart and engine of Scrum, being abolished? Why was this decision taken? I read again the previous scrum guide to find some answers. I put my accumulated knowledge and experience to the test, but in the end a colleague whom I supported in becoming a Professional Scrum Master gave me a decisive impulse.
He pointed out that almost everything that you can say about the Dev Team, can also be said about the Scrum Team as a whole: Self-organizing, both. Cross-functional, both. Deliver a “Done” increment, both. If you look at the following quotation, you can confidently replace the term “dev team” with “scrum team” without changing anything in your daily work.
The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of “Done” product at the end of each Sprint. [..] Only members of the Development Team create the Increment.
If you can replace the term “Dev Team” with “Scrum Team”, why would you need a sub-team just for development? In simple terms, all you need is a Scrum Team, which prototypically consists of Developers, a Product Owner and a Scrum Master. Easy!
But what are the concrete consequences? For example, does anything change for the Sprint Backlog?
What’s about the Sprint Backlog?
In simple terms, until the Scrum Guide was updated, the dev team was the owner of the Sprint Backlog, which could only be changed by the dev team. In the same way as the Product Owner is accountable for the Product Backlog.
This was originally intended to prevent disturbances. Because the planning should always be in the hands of those who know best, those who do. So, what happens then with the Sprint Backlog? Who will own the backlog now that the dev team is abolished? And if ownership is the responsibility of the Scrum Team as a whole, how do you deal with the possible danger that Product Owners or Scrum Masters could intervene in the Sprint Backlog to pursue their own interests?
Answer: Individuals and interactions over processes and tools!
In the end, communication was, is and will remain one of the decisive criteria of a successful Scrum team to prevent disruptions. Afterall, if everyone in the Scrum Team is looking toward achieving the same goals; why would you need more rules?
Sprint Goal is now a Scrum Artefact
Very very good change in my opinion. The capacity of a Scrum Team to manage itself, to plan and to achieve its sprint goal is crucial. A Sprint Goal creates focus and facilitates the decision of what to do — or not to do — during a sprint. The Scrum Team should therefore ask themselves everyday:
Can we reach our goal? If not, in what way do we need to adjust the plan?
The Scrum Team should not be afraid to remove planned backlog items from their planned sprint if it serves the sprint goal. A Team should not ask themselves whether they can complete their Sprint Backlog but whether the Sprint is still worth it? This is the reason the Scrum Planning topics were adapted to include the following question: Why is this Sprint valuable?
By upgrading the sprint goal to an artefact, the importance of delivering something of value becomes more apparent. Scrum teams are thus forced to specify their own goals. This also helps the product owner to plan for the future or to think about what the next sprint goal might be …or to imagine what the next sprint’s goal could be.
Addition of Product Goals
Which brings us to the next point: Product Goals.
Here is something totally new. Product Goals will support the definition of a big and bold Product Vision and to derive impactful Sprint Goals from it.
The idea behind this introduction is about creating a higher level in the product definition, with the features or milestones that the Scrum team wants to achieve in the coming months, years or decades. High performing Scrum Teams focus toward a vision. They do not select the X top items from the Product Backlog as Sprint Backlog, only because X matches their Velocity. They select carefully their Items in order to achieve their next goals. Focusing on a Product Goal leads to Sprint Goals being defined, which in turns into Product Backlog Items being selected for a Sprint.
They will help the Scrum Team to focus on the “WHY” first and foremost.
Even though, I think there is a danger that many people will misuse these product goals to push inappropriate project management techniques into Scrum; I have seen enough Product Owner struggle on this topic to support the addition of Product Goals.
Concretely, I think a lot of teams are already using things like Epics. There Epics are too often used only to categorise different Product Backlog Items, and not as Huge Feature to be developed in the future. The change in the Scrum Guide 2020 should be a good trigger to clean your Product Backlog and to turn your Epics into clear and transparent Product Goals that you want to achieve.
Making Scrum ready for scaling
Scrum was designed with one team in mind.
One Scrum Team, One Product, one Product Owner, one Scrum Master, One Dev Team, One Increment. Easy!
But with the increasing complexity of projects and tasks, the need has arisen to scale Scrum, to deal with more complex issues that a team alone is not up to. Nowadays there are a lot of frameworks that start exactly at this point and promise success, but work more or less well in practice. In contrast to these frameworks, Scrum did not really address this growing demand — until Scrum 2020.
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.
The changes in the Scrum Guide 2020 provide clarity here. It is now also formally OK if several Scrum teams work on the same product as long as they have the same product goals, the same Product Backlog and the same Product Owner. The definition is clear, easy to understand and strait forward to implement — event though the devil will again lie in the operational details.
It remains to be seen how this will affects the various Scrum Scaled Frameworks out there, but it will definitely be exciting.
TL; DR
The Scrum Guide 2020 contains great changes: The dev team is formally abolished; sprint goals are now a mandatory Scrum artifact and product goals have been added.
How will these changes affect the daily work? If Scrum is used in a single Scrum team, not so much should change. The team should take a closer look at its sprint goals and keep their focus on business value. The product backlog should also be adapted to include clear and powerful product goals, to drive the Scrum Team focus over several sprints.
But if you use Scrum with several Scrum teams, the new Scrum Guide will definitely help you. The addition of the product goals will ensure that all teams are steered in the same direction, but at the same time leaves each Scrum team the freedom to achieve their own sprint goals in a self-organized way. This simplification will help many teams around the world scale without the need to use complicated or cumbersome frameworks.
What is left is to wish a happy 25th birthday to Scrum and success to all Scrum Teams for the decades to come!
