#NoEstimates isn’t as revolutionary as people are trying to make you believe
The #NoEstimates movement is gaining more and more traction. I wanted to understand why, so my team experimented with it for 3 months. After working with it for a quarter, I don’t believe it’s as game-changing as #NoEstimates proponents are trying to make us believe.
It doesn’t make a big difference as to how much time a team spends on estimation. It doesn’t fundamentally alter the way a Development Team works. #NoEstimates also comes with obvious downsides that may make a team lose way more time than is saved on the act of estimation.
Before we discuss the benefits and disadvantages of #NoEstimates, let’s first discuss the reasoning behind the movement.
Why do #NoEstimates?
The #NoEstimates movement claims that we should stop estimating Backlog Items for three reasons:
Accurate estimation is impossible.
Estimates can put unnecessary and unproductive pressure on your team.
Estimation is waste, so better to spend as little time on it as possible.
All these points are reasonable, and I agree with them. Estimates are handicapped by what you can know beforehand. Estimates will always be off, no matter what you do. Using estimates to forecast and promise timelines can result in undue pressure on your team.
Your team will always have unknowns in their work — and that limited knowledge before doing the work is the largest element of uncertainty affecting all estimates. There is nothing you can do to remove this uncertainty, unless you start doing the work.
The drive to complete work as estimated, even when those estimates are wrong, can lead to lead to unhealthy pressure, cutting corners, and in the long run, to less progress.
I don’t believe estimates cause this pressure on a team. The way those estimates are treated, communicated and understood is what causes problems. Estimates on timelines need to be updated as more information becomes available. Only when Scrum Teams cling to initial estimations and timelines, perhaps due to outside pressure, despite more information and better understanding being available, you’ll inevitably get in trouble.
I don’t agree that abandoning estimation is the solution. Luckily, the #NoEstimates movement is on the same page about this. The name is misleading. #NoEstimates doesn’t mean you don’t make estimates. It means you estimate differently.
Confused yet? I’ll do my best to try and break it down in a simple way.
Why #NoEstimates is actually a form of estimation
When you work with Scrum, a form of estimation is mandatory. If you’re skeptical about this, here’s what’s written in the Scrum Guide:
Product Backlog items have the attributes of a description, order, estimate, and value. - Scrum Guide, Nov 2017
Product Backlog Items in Scrum must have an estimate. That can be an explicit estimate, like when you use Story Points, or an implicit estimate, by slicing items, so they fit in a Sprint. No matter what approach you decide to use, the Development Team has to make the following call: do we believe it fits in a Sprint? By asking and answering this question, the team has already produced an estimate.
I can explain it more clearly by comparing #NoEstimates with Story Points. Estimation with Story Points usually means you agree on a number from a Fibonacci-like sequence together:
1 2 3 5 8 13 20 40 100
When you do #NoEstimates this sequence simply gets reduced to two numbers:
1: it fits in a Sprint
0: it doesn’t fit in a Sprint
Basically, #NoEstimates shrinks the Fibonacci-like sequence to two buckets: it fits in a Sprint, or it doesn’t. You still need to have the same conversations you have when you do Planning Poker, you just have a smaller estimation range to select from.
When team’s estimate is 1, they usually have more conversations to see if it can be sliced smaller to improve flow and predictability. This is not strictly necessary when you do #NoEstimates. If the answer is 0, the team must discuss to see what can be done to make it smaller. It might also be that there is uncertainty, risk, or complexity that needs to be addressed first.
If you agree with my conclusion that #NoEstimates is still a form of estimation, what’s the impact of stopping with Story Points and using #NoEstimates instead?
With #NoEstimates the amount of time you spend estimating won’t change significantly
In our Scrum Teams, we spend 1 hour on refinement per Sprint of 2 weeks. During this hour, we follow 4 steps:
Write the Product Backlog Items together as a Scrum Team. The Product Owner explain and discusses the why and what.
We discuss how to build it on a high-level. Just enough so we are reasonably confident to understand what we need to do.
We collaborate to figure out how we can split the Backlog Item so it is sliced in the smallest possible way, while still delivering value.
If the Backlog Item is sufficiently clear, we estimate.
When we started doing #NoEstimates, we simplified step 4 by replacing it with the question: does it fit in a Sprint? If yes, then it’s ready to be picked up. If no, we slice the Backlog Item smaller together. This question is easier to answer and definitely takes less time.
But the estimation part is actually the smoothest part of refinement that takes the least amount of time. If there is disagreement on the estimate, you talk about it until a better common understanding of the Backlog Item is reached. The actual act of estimation takes less than 20% of the 1 hour we spend on refinement.
By not estimating with Story Points, we save around 10 minutes. This is around the same amount of time as skipping a Daily Scrum with your team. Is this amount of extra time you’ll save really worth all the hype and buzz surrounding #NoEstimates?
We can agree you save a bit of time with #NoEstimates, but what do you stand to lose, and does this make it worth it?
#NoEstimates comes with downsides
When you use #NoEstimates, you lose information that is provided when you use Story Points or another form of estimation:
You are less likely to detect differences in understanding about the work to be done.
You risk not understanding the impact of dependencies.
By not estimating with the full range of Story Points, you get rid of an opportunity to detect differences in understanding.When people give different estimates, this usually means they have a different understanding. The most valuable part of estimation conversations is not about the estimation, but to create a better common understanding.
Estimation is a quick sanity check to ensure everyone is on the same page on what a piece of work entails. This information lost when you use #NoEstimates. The questions “Does it fit in a Sprint?” or “Can we slice it smaller?” simply don’t spark the same kind of conversations as when you do Planning Poker and need to put a number on it.
Now let’s circle back to the benefits of having more fine-grained estimates. As imperfect as Story Point estimates are, they do contain information. User Stories with 3 Story Points are generally (but not always!) smaller than User Stories with 8 Story Points. This information can be useful to manage dependencies.
Imagine you are planning a Sprint with 3 Stories that are dependent on each other. All three stories are 8 Story Points each. Because of this, you may conclude that there is a high-risk you will not be able to complete these three stories if you work on them in the same Sprint.
When you don’t use estimates, you don’t have this information. Proponents of #NoEstimates would argue that you need to slice all Backlog Items to a similar, small size, so it does not really matter which User Story you pick-up. I don’t believe this is always possible.
But I do have to agree, even if you don’t have a Story Point estimate, the team will probably still be able to assess if they run into a problem when they pick up 3 User Stories that are dependent on each other. It will just become a call made from the gut, instead of having an estimate that may remind you of this impossibility.
#NoEstimates sounds cooler and more useful than it actually is
#NoEstimates sounds great, and it is marketed well by the folks supporting the movement. But does it really make such a big difference for how your team works? Absolutely not. #NoEstimates is like the Pet Rock from the 70s— the idea behind it is cooler than what it means in practice.
#NoEstimates is an ill-fitting name. When you do #NoEstimates, you still have an estimate for your Product Backlog Item. It’s just less granular than if you would use Story Points. #NoEstimates reduces the Story Point estimation range to two buckets. Everything else remains the same.
With #NoEstimates:
Less time is spent on estimates, which amounts in total to roughly one Daily Scrum less per Sprint. If saving time is your primary motivation to stop estimating, the pay off is pretty meager.
You lose a valuable estimation conversation to check if everyone has the same understanding. Divergent estimates often mean a different understanding of what needs to happen. Correcting these differences in understanding is the most valuable part of the conversation, not the (potential) change in estimate.
You lose information about the size of Backlog Items that may impact Sprint Planning, especially if there are dependencies.
What I do like about #NoEstimates, is that it can help protect Scrum Teams from companies that suffer from a velocity obsession. There is no velocity, so nobody can pressure teams into increasing their velocity. It may also help shift the conversation from timelines and estimates towards spending more time on discussing the value of Backlog Items.
These are actually the two biggest advantages of #NoEstimates, not the amount of time you will save. The time saving aspect of #NoEstimates isn’t worth it. However, organisations that pressure on velocity and timelines are the least likely to adopt #NoEstimates. So either you gain very little from #NoEstimates, or you’re unlikely to be able to implement it in your organisation.
At the end of the day, I believe #NoEstimates doesn’t make a big difference for your Scrum Team. Based on my personal experience of doing #NoEstimates for 3 months, it isn’t worth all the fuss and attention, but if you like it, please continue doing it.
The biggest value in using a bigger range in estimates isn’t improving the accuracy of the estimate, but having the important conversations that result from divergent estimates. The value lies in having a better common understanding, the change in estimates is often of trivial importance.
Special thanks to Jonathan Odo for his insightful feedback to help make this a stronger piece.