Late last year, Ken Schwaber, Jeff Sutherland, and several of their colleagues announced the updated edition of the Scrum Guide in a very extensive webinar lasting over 2 hours. We have compiled the most important information in 8 points.
1. The bottom line is that Scrum remains Scrum
This Guide was first published 10 years ago and has not been updated very often (the last time was in 2017), but these updates have not affected the fundamentals of Scrum. This time, the aim of the update was to make the document even clearer and to address common misunderstandings.
It is important to note that Scrum is emphatically a framework: it provides a framework within which Scrum teams must define their own processes and practices. It is not intended to be a comprehensive methodology, nor is it intended to be a comprehensive manual.
2. Product Purpose Introduced
It's not often that something new is added to the Guide, and this time, only one new feature is introduced: the purpose of the product.
The product goal is part of the product backlog. It is a commitment that helps to create greater focus and transparency. Perhaps the best analogy is that the product goal is to the product backlog what the sprint goal is to the sprint backlog. Both provide transparency and help to prioritize the goals set. The goal is the same, but the time intervals are different. Breaking things down into smaller pieces is essential when working towards a solution for a large initiative. This significantly helps to align the organization’s business strategy and goals, as well as the direction of the product. In essence, it calls attention to a conscious product strategy and its proper management.
3. Switch from “Development Team” to “Developers”
It is important to emphasize that this is essentially a terminology update. It has no impact on the actual implementation of Scrum, or the collaboration within the Scrum team.
The original intent of the Scrum roles and how they work together are the same. This can help reduce confusion and eliminate various anti-patterns that were misleading within the team. In short, one role is simplified from “Development Team” to “Developers.”
Are developers still creating value additions that meet the definition of Done? But how much!
The intention is to place more emphasis on the Scrum Team as a cohesive unit with a common purpose. The new Guide states: “The entire Scrum Team is responsible for creating valuable and usable increments in each sprint.” While the Product Owner, Scrum Master, and developers are still clearly and independently accountable in their own areas, all three roles must function effectively to successfully operate according to Scrum.
4. Clearer and more concise
The Scrum Guide update focused mainly on better organization, clarity, and readability.
For example, it has always been true that Sprint Planning deals with the why, what, and how questions. The reorganization and rationalization now make this clearer.
Additionally, the sections related to practical implementation were removed: the three questions from the Daily Scrum and the list of activities that are part of the Sprint Review.
5. Self-management instead of self-organization
If Scrum was used well, there is no difference in practice. In English, these terms are interchangeable and we could delve into more complex theories, but the Scrum Guide update was not based on a specific theory or model.
The terminology change will help overcome some common misunderstandings. For example, if the Scrum team experiences too much restriction on its work, blocking its ability to deliver high-value solutions, then it needs to address this itself.
However, there are also boundaries that are okay and don't particularly limit the ability of Scrum teams to self-organize. Instead, they actively work to remove obstacles that hold teams back. Over time, you need to find the right balance.
6. The term “potentially releasable” is no longer used
I would like to see Scrum become more accessible and understandable to non-software teams. Over the past decade, the framework has proven itself beyond software, and the term “potentially releasable” has often proven confusing.
However, for software teams, they certainly still want to deliver potentially releasable software at the end of each sprint. Transparency, progress, quality, and risk management remain high priorities.
However, since everyone's context is different (even when it comes to software), changing the wording helps make this concept more approachable and understandable.
7. Planning retrospective developments into the backlog
There used to be a recommendation that at least one should be planned in each sprint, but the current Guide does not state such a rule. The Scrum team may decide not to plan such an improvement in the sprint. It no longer mandates this practice, instead leaving it up to the Scrum team to decide.
However, it is important to remember that without adoption, continuous self-monitoring by the team is meaningless. If the Scrum team is not improving itself, it is worth asking why this is happening. There are certainly some problems lurking in the background that need to be solved. Maybe Sprint retrospectives only touch the surface, and people are not willing to have difficult conversations. Maybe they do not have enough transparency into the process to see opportunities for improvement. Maybe the team is under pressure to constantly deliver more and more.
8. Formal commitments
The sprint goal and definition of done were also included in previous versions of the Guide. However, with the current reorganization, they have been given a clear “home” along with related documents.
The biggest change is the addition of a product goal, which is part of the product backlog. So, clear commitments are defined for all 3 documents.
Summary
As has been said many times, Scrum is still Scrum.
Scrum can be used well and badly. This update to the Guide will help people apply the framework more effectively in their environments. It will certainly never be perfect, but this version is the best yet.