5 Things You May Think Are Part Of Scrum But Got Removed
How the Scrum Guide moved towards describing the core framework
How the Scrum Guide moved towards describing the core framework
Scrum is a framework to create value in complex environments. It is founded upon the concept of empiricism: transparency — inspection and adaptation. Scrum as a framework is also subject to inspection and adaptation. It continued to have the same objectives, but the rules of the game of Scrum have evolved.
Even if you only take into account the last decade, ever since the publication of the first Scrum Guide, many things have changed. Many things got removed. Some things were added and later removed.
In this article, I will discuss 5 things that were removed from Scrum but have made a lasting impression on the framework.
![](https://substackcdn.com/image/fetch/w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fbucketeer-e05bbc84-baa3-437e-9518-adb32be77984.s3.amazonaws.com%2Fpublic%2Fimages%2F77ce86cb-aa51-47c2-a6d4-02763cd7b8cd_800x368.jpeg)
1. Sprint Backlog items
Product Backlog Items that were selected for a Sprint used to change names. They became Sprint Backlog Items. This is very clear in the Sprint Planning section of the July 2011 Scrum Guide. In the “What will be done” section, the guide discusses Product Backlog Items. In the “how” section, these have turned into Sprint Backlog Items.
There were no clarifications on how these two differed from each other. This only added to the confusion.
The Scrum Guides weren’t very consistent. They sometimes discussed Product Backlog Items where you would expect them to mention Sprint Backlog Items:
“The Daily Scrum is not a status meeting, and is for the people transforming the Product Backlog items into an Increment.” — Scrum Guide July 2011
Since the 4th edition of the Scrum Guide, July 2013, Scrum doesn’t talk about Sprint Backlog Items anymore. We now only have Product Backlog Items. But many still make the distinction between Sprint Backlog Items and Product Backlog Items.
2. Development Team
The latest edition of the Scrum Guide, from November 2020, got rid of the Development Team. No, they didn’t remove the people that do the work from the framework. They removed the team within a team.
All previous editions of the Scrum Guide had teams within a team. You had the Scrum Team and the Development Team. Product Owner and Scrum Master were part of the Scrum Team. But they weren’t part of the Development Team. This caused silo-thinking, us vs them.
To stress that Scrum is all about teamwork, the Product Owner, Developers and Scrum Master are now all part of one team, the Scrum Team. This Scrum Team is together accountable for creating valuable useful increments. The latest Scrum Guide reminds us on different occasions that this means the whole Scrum Team. The is a telling line:
“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.” — Scrum Guide 2020
This snippet tells us that any activity is in the end for the team as a whole, even though these may be things that are primarily for a Product Owner, Developer or Scrum Master.
Still, the idea of a team in a team exists in many minds. This is especially true with the position of the Product Owner, often considered to be some sort of higher-ranked role.
3. Undone Work
The 2010 Scrum Guide dealt with undone work, albeit as a tip:
“‘Undone’ work is often accumulated in a Product Backlog item called ‘Undone Work’ or ‘Implementation Work.’” — Scrum Guide 2010 tip
Although as a tip, it got mentioned 12 times. It existed to be more accurate in reflecting the progress of a team. Undone was tightly coupled to the commitment of delivering the items according to the planning.
This all brought a focus on delivering output and ensuring the team did this Sprint after Sprint. It did not do justice to why Scrum exists in the first place: to create products of value in complex environments. It neglected the very foundation of Scrum: empiricism.
The second edition of the Scrum Guide did away with this concept of undone work. But the damage had already been done. Up to this day, teams still believe they should commit to their planned work and log progress meticulously. By doing this, they completely ignore the concept of Sprint Goal.
4. Testing as part of Definition of Done (DoD)
Yes, you did read it right. Scrum removed testing from the Definition of Done. But, they had a good reason for it.
The first Scrum Guide was very elaborate about the Definition of Done. It stated the following should be part of this DoD:
analysis
design
refactoring
programming
documentation
unit testing
system testing
user testing
regression testing
performance testing
stability testing
security testing
integration testing
This is fairly prescriptive, to say the least. Teams basically got instructions on how to do their work. This limited the options to self-organise the work.
As of the 2nd Scrum Guide, almost all of this was removed. Only this remained:
“Each Increment is additive to all prior Increments and thoroughly tested, ensuring that all Increments work together.” — Scrum Guide July 2011
It made sense. These were the days that Scrum was mainly targeted at software development. While there may be multiple ways to create the software, some sort of testing is always required.
But Scrum moved beyond software and is now presented as a framework for all sorts of complex products. Some of these products don’t require testing. On top of this, the Scrum Guide got less prescriptive. The latest version focuses on the framework itself. It discusses how Scrum works. It doesn’t want to tell you how to create your product.
5. Self-organising teams
Another striking change is the removal of the term self-organisation. Teams are no longer self-organising.
Instead, teams are self-managing. One could argue this is essentially the same. You could have quite a debate on that, but I do largely agree. Still, it bothers me. Self-organisation has been an established concept in the agile environment. It’s one of the principles of the Manifesto for Agile Software Development:
“The best architectures, requirements, and designs emerge from self-organizing teams.” — Manifesto for Agile Software Development
Throughout the years, Scrum kept calling it self-organisation. This ended in November 2020, when the Scrum Guide introduced self-management. Scrum Teams are still responsible for the same things as before. They could have kept the universally understood term self-organisation.
The result is confusion on the terms that doesn’t serve anyone.
More clarity, but not always
The current Scrum Guide is more focused on empiricism than the earlier versions. Gradually, the definition of Scrum moved away from focusing on How and WHAT towards WHY. This brought more clarity.
But this hasn’t been the case for all changes. For example, I still have issues with the change from self-organisation to self-management. But Scrum is not at the end of its journey. It will continue to evolve. Perhaps this anomaly will be repaired in the next version.