How Estimation Got Removed From Scrum
Discover more from Ageling on Agile
How Estimation Got Removed From Scrum
#NoEstimates and Scrum
#NoEstimates and Scrum
Ask any developer about estimation and get ready for a spirited discussion. Given this, I find it curious why the Scrum Guide doesn’t mention the words estimate or estimation at all. What happened? And what does this mean?
In this article, I will show how estimates and estimation used to have a prime role in Scrum and how it (almost) completely vanished from the Scrum Guide.
Estimates in the 1st Scrum Guide — focus on output
The first Scrum Guide, published in 2010, discussed the estimation left, right, and centre. The rules and tips were shaky at best. If you believe Scrum is about achieving your goals and creating value, then get ready to be shocked by what the 2010 Scrum Guide had to say about estimation.
Product Backlog items needed to have the following three attributes:
A description
A priority
An estimate
This first Scrum Guide even informed us how to get better estimates:
“Better estimates are made based on the greater clarity and increased detail.” — Scrum Guide 2010
I don’t think the writers of the Scrum Guide ever imagined the way this would be picked up. But the statement had many jumping to the wrong conclusion. Many people believed they needed to improve their estimates by spending more time on analysis.
This caused analysis paralysis. Teams ended up overthinking their items, a very costly exercise. They spent a lot of work trying to predict what would happen. Teams did work that ended up being in vain due to new learnings.
The first Scrum Guide also instructed teams to estimate the remaining effort for items that were in progress. Why? Well, to have an accurate release burndown graph. This was a tool that incentivized the focus on output instead of the desired focus on the outcome.
The original Scrum Guide had more to say about estimating:
“Release planning requires estimating and prioritizing the Product Backlog for the Release.” — Scrum Guide 2010
Again, the writers of this first Scrum Guide didn’t intend for you to make detailed plans spanning multiple Sprints. But many teams and their managers read it like this. This is no surprise. People new to Scrum would recognize the planning practice from when they worked with traditional project management approaches. So they continued to create these long-term plans.
We also had the term “undone”. The 2010 guide introduced “undone” work, as a tip. It discussed the practice of estimating how much work of an undone item was finished and how much still should be done. Teams would then “accurately” reflect this in their burndown chart.
It was a suggestion that caused teams to put even more effort into estimating. This was a highly questionable tip. Teams should not focus on burning work, they should focus on goals and outcomes. This tip moved them away from this.
If you think all of this was bad advice, there’s even more. The 2010 Scrum Guide also discussed breaking down items into tasks and estimating those. And tasks that were in progress should be re-estimated to show the remaining work. This is another example of focusing on providing a status on the delivery of output, not on outcome.
Estimates in the 2nd Scrum Guide — damage control
The second Scrum Guide from July 2011 repaired many things from the predecessor that didn’t serve the purpose of the Scrum framework.
It did still mention that Product Backlog items should have the attributes description, order, and estimate. It also still said you get more precise estimates with greater clarity and detail. So the pitfall of overanalysing still existed.
But everything else was removed from the guide. No more splitting into tasks and estimating them, no more re-estimation, no more undone work.
This 2nd version of the Scrum Guide did emphasise an important thing: the Development Team (Developers in the 2020 Scrum language) determines the estimates. No one else.
The next 4 Scrum Guides from October 2011, 2013, 2016, and 2017 did not change their vocabulary on estimating. The guidance for detailed estimation, which existed until very recently, drove teams to an analysis paralysis trap.
Estimates in the 7th Scrum Guide — no estimation
It took 10 years before anything changed. But the 7th Scrum Guide, from November 2020, has changed things drastically. The words “estimate” and “estimation” are nowhere to be found.
But… there’s the word “size”. What’s the difference between an estimate and size? You could argue you still need to estimate to understand the size of an item. This would then imply nothing significant has changed.
But there are ways to understand the size of an item without estimating it. Size does seem to indicate relative comparison versus precise estimation craziness.
To understand how the new Scrum Guide addresses estimation without mentioning it, I find it useful to look at how it discusses refinement. In previous versions of the Scrum Guide, this used to be the activity that included estimation.
Well, refinement has a less prominent place in the Scrum Guide now too. What’s left is this:
“Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing activity to add details, such as a description, order, and size. Attributes often vary with the domain of work.” — Scrum Guide 2020
A Product Backlog item now MAY have the following attributes:
A description
An order
A size
Product Backlog items could have other attributes. This means that they could also have no indication of size.
The new Scrum Guide vastly differs from the 2017 version. There are a couple of reasons for this:
It is less prescriptive. The 2020 Scrum Guide is smaller than the previous one. It is only 13 pages. 6 less than the 2017 version. Scrum should be a framework, not a method. So topics that don’t serve to explain the framework are largely removed.
It is targeted at all kinds of complex product environments. This is why the writers of the Scrum Guide removed many practices that were more software specific.
The Scrum Guide is more about reaching your goals as the way to manage complexity. It no longer has remnants of output thinking and firmly underlined the importance of outcome thinking. Work may be too complex to estimate. Therefore estimation may not be useable everywhere.
It appears that Scrum was influenced by the #NoEstimates movement. This movement criticized Scrum for advocating estimation in complex environments. This may have triggered the writers to move from the term “estimate” to “size”.
Goodbye estimation, hello focus on outcome!
Scrum has a long history of prescribing how to estimate. Initially, estimation was a key activity for Scrum Teams. Swiftly after the first Scrum Guide, several questionable estimate practices were removed from Scrum. But estimates were still deemed necessary.
The latest edition of the Scrum Guide doesn’t mention estimates at all. It discusses the size of items once. But it also stresses that an indication of size is not always required.
I believe these are vital changes. Previous versions of the Scrum Guide had incentives to focus on output, ignoring value. The 2020 Scrum Guide helps the Scrum Teams to have their focus on achieving their goals, to commit to outcomes.
While it may be uncomfortable to let go of estimation as the Scrum Guide has, we will all benefit from a shift from outputs to outcomes. I find it refreshing and liberating. Why don’t you give it a try?
