#NoEstimates
Estimation is wasteful, but many teams still abide by it. Let’s debunk this myth.
The #NoEstimates discussion and my experience of having left estimates long ago led me to write this article. I argue that estimates are mostly a waste of resources. Finally, I’ll present the alternative (which ends up rendering sprints unneeded). Note that this advice follows The “Just Sharing” Principle.
Estimating is guesswork
Estimations are guesses. You may argue that they’re educated guesses, but educated on what? We’re always solving new problems. The world keeps spinning: technology changes, and users’ problems evolve. We’re always doing research and adapting.
A product is, by definition, inherently unpredictable. You’re in a constant state of discovery. When you get feedback on something you delivered, you reshape your understanding of the domain. You never really know the following stories, as they are constantly being shuffled, sliced, discarded, and pivoted — if not, you may not be interacting enough with the users; you’re likely following an outdated plan. There are unexpected blockers and obstacles. The uncertainty is higher for stories you’ll start a week later.
Software development is not carpentry. Almost everything a developer writes is unique, they have never built that particular thing before. We are not cabinet makers repeating a variation of something we’ve built hundreds of times before. Why are developers expected to estimate tasks at all?
We don’t know how to estimate. We keep guessing and failing but wishfully believe we’re getting better. Isn’t this a form of superstition? As in the stock market, past behavior doesn’t tell much about the future. Estimation is, therefore, deceitful. Try using random estimates (or always estimate with a 2); you’ll end up roughly the same, and no one will miss the estimates.
Something always goes wrong. […] the myth of the “optimistic” estimate — how long a project would take if everything went right. Such “estimating” might just as well be based on the assumption that the Laws of Thermodynamics would be repealed during the project. The Psychology of Computer Programming
Estimation is waste
In lean software development, waste is any activity that does not directly put something your customers find valuable into their hands. For example, updating a tracker, managing feature flags, and attending meetings. It’s meta-work and bureaucracy; it’s overhead that you should fiercely aim to reduce by asking if it’s worth it.
The epitome of waste is when the overhead work decouples from the actual work. It happens insidiously, and once you notice, it’s being done for its own sake, most likely due to tradition. The overhead becomes the goal.
Estimating/sizing is a prime example of overhead work that should be questioned and, in many instances, abolished. Estimates are an artificial concept. Take a step back and question its relevance. Why do teams estimate work? Predictability? Teams need to know how much fits in the sprint, but is it helping? And why is abiding by the sprint (another artificial concept) so relevant?
But does it really matter if you’re able to predict exactly when something is finished? If you’re confident you’re making the best progress you can towards delivering something valuable, does it matter if it’s slower than you expected if that expectation was always flawed and imprecise to begin with? Why estimates and timelines are the biggest enemy to delivering value
Fast forward to the retro, and someone says: “We should estimate higher next time!”. Did you try to improve your estimate skills? You may even get better at the guessing game, but the goal is to deliver value, not to produce finer waste.
There is surely nothing quite so useless as doing with great efficiency what should not be done at all. (Peter Drucker)
Additionally, each person interprets story points subjectively, and the team needs to keep re-revisiting their definition of the baseline story. Besides, in Scrum, the team commits to a sprint goal, not a set of stories. This makes estimation even less relevant (if you use Scrum). By the way, there’s no single reference to estimates in the Scrum Guide.
Estimating tasks will slow you down. Don’t do it. We gave it up over 10 years ago. Today we have good data from Rally on 60,000 teams. The slowest estimate tasks in hours. No estimation at all will improve team performance over hour estimation. (Jess Sutherland; co-creator of Scrum)
Using story points doesn’t solve the time estimation problem. Story points measure complexity, not time! Story points were invented to obfuscate duration so that certain managers would not pressure the team (Ron Jeffries). They are a team tool instead of a way to manage customer expectations or evaluate velocity — unless you’re fine with lying and deceiving.
I like to say that I may have invented story points, and if I did, I’m sorry now. Story Points Revisited (Ron Jeffries)
Estimation is harmful
Who wants estimates? What problem do they solve, and could you solve it any other way? What’s their return on investment? In hindsight, did estimates change anything in the big scheme of things? Do you want to make gambling-based promises to clients and customers? Is evaluating people/teams based on such a dysfunctional concept fair?
Estimation appears to be an indisputable process; nobody questions it, but it’s often harmful. Estimates are not the biggest problem; estimate-driven development is. Namely, when the team behaviors are shaped by the estimates as if they were the goal. Estimation creates too many distractions and bad practices. As per Goodhart’s law, when a measure becomes a target, it ceases to be a good measure. For example:
- heated meetings dedicated to estimates;
- doing many tiny fake stories to increase velocity;
- postponing important work because it does not fit the sprint;
- trading off on quality so the story fits the sprint
- running behind the estimate and losing sight of the real problem;
- demanding results managers based on estimates.
Generally speaking, estimates are likely to be wrong, and they focus our attention on the cost of things rather than on value. The Nature of Software Development
I’ve seen teams fiercely fighting over a “2” vs. a “3”. Often, estimation was solely about who was right. After a long hour, the participants’ focus plummeted, and all left the meeting tired. What a way to start the week! Also, during the sprint, estimates were a source of anxiety. All this takes a toll on you. You can only do so much in a day at your best. Is it sustainable? Imagine all that energy applied to properly understanding, slicing, and solving user stories. That said, make sure you consider the psychological factor.
In estimate-driven development, the teams’ efforts are shifted toward artificial concepts and away from their original mission (recall from the agile manifesto: Individuals and interactions over processes and tools). Estimation is institutionalized wishful thinking. Don’t try to predict the future; act on the present instead.
Estimating is impracticable
A user story is a promise for a conversation. It’s called a user story since it represents a user problem, not a solution. User stories don’t solutionize, are not prescriptive, and don’t describe steps or requirements. You’re doing it wrong if you’re talking about UI controls or databases.
If a user story is a user problem, how can you estimate the effort of a problem? You can’t. It’s nonsense. You can’t estimate beforehand, as you don’t know which solution will be picked later. It’s up to the team to find the solution to the problem described in the story after starting it (and no solution should be force-fitted into a timebox). Sometimes, the team needs to try other solutions. Furthermore, a user story can spawn across many others.
If you can confidently estimate, it’s because your stories are solutions. Someone probably did all the work upfront before, and now you have lists of requirements masked as user stories. You’re locked to dictated solutions too early. That’s the waterfall approach.
#NoEstimates
Even if estimations still have some value, are they worth it, considering all the waste and damage they bring? The only good side of estimating is talking about the problem and letting everyone be on the same page. However, you can do that without estimating (ideally, you’d do it in the last responsible moment when kicking off the story). Ask why you need to estimate and work on that instead.
The bottom line of the #NoEstimates movement is to make the stories so small that estimating becomes pointless (pun intended). If properly sliced, stories are on average a small size. This alone probably defeats the need to estimate. Well, estimating becomes just counting stories, which bestows a good level of predictability.
With small stories, a steady stream of user value gets delivered (user value means everything that makes a difference for the better, even if tiny). Besides predictability, it brings other benefits such as shortening the feedback cycles, a more granular prioritization, reduced risk, easier understanding, ease of testing, a sense of progress, etc. (this closely relates to the benefits of CI/CD since it’s impractical with big stories). With small stories, we embrace uncertainty.
The key question is to find the most valuable things to do, and to do them quickly. Doing them quickly comes down to doing small slices of high value, and iterating rapidly. Story cost estimation doesn’t help much with that, if at all. […] The best way to deliver value isn’t more, more, more, it’s to do small valuable things frequently. If instead of estimating stories, we slice them down to “small enough”, we can come to a smooth flow of value, delivering all the time. Story Points Revisited
Don’t ask if the story is too big. Instead, ask if it can be sliced and still bring value. This type of slicing takes some time to get used to. Slicing in terms of user value is orthogonal to slicing by layer or tech (backend vs. frontend). This precludes that teams should be self-sufficient, having all the skills to deliver value. Beware that #NoEstimates is not the goal; it’s just a side effect of working in baby steps.
Common questions
“Aren’t you suggesting to drop estimations just because they're hard?” Yes, and that’s an argument. We have limited energy, so we need to be wise when picking what we do (besides, the burden of proof of worthiness is with the ones proposing the estimates overhead). When you weigh all the factors that come into play (uncertainty, overhead, toxicity, psychological factors) versus the benefits, it does not seem to be worth it in many cases. Surely, this is not the case everywhere, but at least question it and take your conclusions. Coupled with a lean mindset, user-centric approach, and customer collaboration, ditching estimates made my developer life simpler and more pragmatic.
“How do you know if you need to split if you don’t estimate?” My rule of thumb is always to split, not because it’s big but because it can be independently delivered and still bring value. Small stories allow more granular testing and prioritization, earlier and more frequent feedback, less risk, more focused conversations, etc. Beware that you don’t slice when the story is created but at the last responsible moment.
“But won’t some stories be too big?” Yes, some stories are hard to slice and still bring value. In my experience, these are the exceptions and not the rule. Before giving up, there are ingenious ways to slice that you should be aware of.
“Won’t some customers still want to know when the full capability is delivered?” If you properly slice user stories, deliver them iteratively, and get constant feedback, the need to know dates fades away. When customers see steady progress, it’s less likely they worry so much about “when will it be done” because it’s done nearly daily. “If the train leaves every 5 minutes you don’t care about a timetable. If it leaves every 2 days you want to know *exactly* when it leaves”. Besides, if the customer is part of the development effort through constant collaboration, there’s less meaning in asking when it’s done. Finally, if there are real deadlines, you must compromise on the scope side (but rarely on the quality side).
“How do I measure velocity?” If your managers use velocity to judge teams, it’s probably an ingrained mindset that you lack the power to change. Also, if you’re too focused on velocity and burndowns, you are looking at the wrong metrics. The DORA metrics are the only metrics that matter and have a scientific backup. In particular, the delivery frequency measures how often you release to production. This is backed up by the #NoEstimates mindset because you’re constantly releasing.
