Why Estimation is a Waste of Time For Many Projects

• Estimation wastes hundreds of hours without improving project outcomes—code delivers, not guesses.

• Hardware is cheap, human labor isn't—stop burning dev time on planning theater.

• Focus on fast delivery of measurable business value, not timelines no one trusts anyway.

Before I start, I want to say that I haven't needed to estimate any software development effort since 2010. I've delivered over 300 projects for around 70 clients successfully. Many of these have been "turnarounds" or "rescues" from previous failures, where estimating software development was the basis of their KPIs. Note that on many of these rescue projects, they were on-time and on-budget, but their sponsors pulled the pin because they weren't confident that the project would deliver something useful.

Here's my professional opinion, which I'm going to run you through in this article:

Since the year 2000, estimating how long it will take to build a system is quite literally a waste of time.

But I don't expect you to take my word for it. Ask any software engineer with more than a couple of years' experience, and they will tell you the same thing.

In fact, this has been common knowledge since the 50s and 60s when IBM pioneered mass-produced computers. It was IBM's Fred Brooks who first pointed out the software estimation fallacy in his seminal 1975 book, The Mythical Man-Month. Fred Brooks was responsible for developing the System/360 series of IBM computers along with the software that ran them (OS/360). Presumably, in his spare time, he was also a pioneer in Virtual Reality (VR) research and founded the Computer Science Department at the University of North Carolina—no slouch.

Fred's credited as having "a lasting impact on software engineering practices," and many computer science degrees still use his book as the basis for understanding the limitations of estimation. Complexity theory, now highly regarded in software engineering, backs up Fred's earlier work, drawing a line between estimating predictable but complicated things (like building the System/360) and estimating seemingly small but unpredictably complex things (like building software, OS/360).

And yet here we are in both traditional and agile projects spending an inordinate amount of resources estimating how long it will take to build stuff.

To understand what I mean by "a waste of time," let's consider the "sprint planning" activity widespread in agile teams, particularly in the "Scaled Agile Framework" or "SAFe," which is the one I most frequently have to pick up the pieces from.

This planning activity typically takes one or more days per sprint for the median 3-month project, with median sprints lasting two weeks. The whole team is required to be present for sprint planning. For a typical 10-person team, planning occurs six times during the three months, totaling 480 hours spent estimating stuff—equivalent to a full-time developer working for three months. That's a LOT of code.

Question: Is it worth cancelling a full-time developer for three months to estimate?

The correct answer is, "In the olden days, it was the best we had, but it's no longer relevant." From the 50s to the 80s, the cost of writing code mostly lay in the expensive computers developers had to use. Machines like the System/360 cost significantly more than the humans writing the code. Developers had to estimate coding time carefully to book expensive computer usage in advance—each run could cost $10-$100k in today's terms. In that context, extensive estimation to avoid mistakes made sense.

From the 80s onwards, computing costs plummeted. Today, the cost of a developer's laptop or desktop is insignificant. Now, the economics are entirely reversed—the cost of human labour dominates project budgets, making any non-coding activity highly questionable.

The only reason we would hold onto analysis and estimation now is if it genuinely helped predict or control the business outcome—the actual business benefit of the project. But we've known for decades that the time taken to build specific features is irrelevant because other factors impact business outcomes more fundamentally. Over 50% of projects fail to deliver their intended benefit, according to sources like the Project Management Report for 2023.

These projects don't fail due to poor estimation; they fail because they don't prioritise effectively, and often deliver nothing valuable. Trying to estimate how long features will take is nowhere near as valuable as:

• Understanding what business benefit will be delivered in the first 20% of the project budget.

• Knowing which features will most significantly impact business outcomes and building those first.

• Getting something basic into the hands of operational staff, allowing them to use it on a small scale and iterating based on real-world feedback.

Today, documenting and estimating what you might build is never as useful as writing code. For the cost of estimation, you could write code and throw it away multiple times—a process extremely valuable because actual use is the only way to know if you've solved a problem. Documentation and estimation became obsolete once hardware became the cheapest component of a project.

So why are we still estimating?

The simple answer is inertia—it's what we've always done. The main purpose of estimation is to predict results for corporate governance and legal compliance (especially in publicly listed companies). We need to promise something for the funding provided.

But here's the thing—we don't need to promise specific features anymore. We can skip directly to promising specific business benefits.

I no longer take jobs based on a scope of features for a set price. Instead, I promise a tangible business benefit, such as halving average call handling times or reducing offer-letter issuance from 13 weeks to 3 weeks.

Holding me accountable is straightforward—far easier than scope-based or plan-based governance. If I haven't delivered measurable benefits by the time we've spent around 20% of the budget, we know immediately that we're off track. If 50% of the benefits aren't delivered by the time we've used 60% of the budget, I should be reprimanded or replaced.

This simpler, tangible, and less costly governance dramatically reduces project financial risks and deliberately steers toward success. Now that computing isn't holding us back, the emphasis shifts entirely to writing valuable code and clearly understanding what code will improve outcomes.

Stop estimating—it's a waste of time. Instead, use that time to write code and determine what is the next most valuable feature to build to deliver meaningful business benefits to users.

When you're ready, here's how I can help:

Andrew Walker
Consulting to for-purpose CEOs to deliver more impact with existing teams and systems - by freeing humans up from admin.
https://www.linkedin.com/in/andrew-walker-the-impatient-futurist/

Did someone forward this email to you? Want your own subscription? Head over here and sign yourself right up!

Back issues available here.