Why Software Estimates Are Useless
How long will this take?
It’s the most common question in software development. It’s also the most damaging one. After years of leading teams and shipping products, including the backend for Europe’s largest EV charging network, I’ve come to a simple conclusion. Estimates are useless. And worse, they’re actively harmful.
The chain reaction
Here’s what actually happens when you estimate:
Estimates become deadlines. A PM or PO asks “how long?” You say “maybe three weeks.” They hear “three weeks.” It goes on a roadmap. It gets communicated to stakeholders. Now it’s a commitment.
Deadlines create overwork. The estimate was wrong (it always is) and now the team is crunching to hit an arbitrary date that was never more than a guess.
Overwork produces bad software. Corners get cut. Tests get skipped. Tech debt accumulates. The team ships something fragile and moves on to the next deadline.
Bad software creates dysfunction. Bugs pile up. On-call becomes miserable. Morale drops. The team slows down, which leads to more pressure to estimate accurately, which leads to more estimates.
Estimates lead to deadlines, deadlines lead to overwork, overwork leads to bad software, and bad software leads to dysfunction. I’ve watched this cycle play out at every company I’ve worked at.
We don’t know how to estimate. Get over it.
The Standish Group’s CHAOS Report is often cited to claim that 80% of software projects fail. But that’s not the real takeaway. The real takeaway is that we are fundamentally bad at predicting how long software work will take.
This shouldn’t be surprising. Software development is exploration. We learn about the problem as we work on the solution. Asking a developer to estimate a task they haven’t started is asking them to predict the future about a problem they don’t fully understand yet.
And story points? They were invented to obfuscate time. That’s it. They were supposed to separate effort from duration, but in practice, everyone just converts them back to hours anyway. Even Ron Jeffries, one of the creators of story points, has said they were a mistake.
Estimates are waste
Here’s the lean perspective: any activity that doesn’t directly contribute to putting something of value into customers’ hands is waste. Estimation sessions don’t ship features. They don’t fix bugs. They don’t make the product better.
A team spending half a day in estimation meetings every sprint is burning time that could be spent building. Multiply that across an organization, and the cost is staggering.
What to do instead
If you absolutely need to forecast, there are better approaches than asking developers to guess:
Use complexity buckets, not numbers. Instead of “how many hours,” categorize work as:
- Trivial
- Easy
- Normal
- Hard
- Herculean
- Don’t know
“Don’t know” is the most honest and useful category. It means the work needs to be broken down further or spiked before anyone can say anything meaningful about it.
Count stories. If you need projections, just count the number of stories completed per week. Over time, this gives you a throughput number that’s far more reliable than any estimate. No estimation meetings required.
Focus on prioritization, not prediction. The real question isn’t “when will this be done?” It’s “are we working on the most important thing?” Use a story map to visualize priorities and make sure the team is always working on what matters most.
Make work small. If every story is roughly the same size (small), you don’t need to estimate. You just count. This also forces you to break work down properly, which is valuable in itself.
The uncomfortable truth
The desire for estimates comes from a desire for control. Leadership wants to know when things will be ready so they can plan around it. That’s understandable. But estimates give the illusion of control, not actual control.
You know what actually gives you control? A team that ships small increments continuously, a backlog that’s ruthlessly prioritized, and a culture where it’s safe to say “I don’t know how long this will take, but I can show you progress by Friday.”
That’s harder to put on a Gantt chart, but it’s how good software actually gets built.
Further watching: Allen Holub’s #NoEstimates keynote is the best presentation I’ve seen on this topic.