Estimates do not give you what you want

Humans are bad at estimating. And within the context of a complicated business, estimating is even harder.

What businesses really want is risk reduction, decision-making information, predicatbility, and accountability. And estimates do not provide any of these.

Estimates are a guess about an unknowable future but they are used as a low-quality proxy for what is really required. Working with estimates leads to errors because they do not focus on what the business really wants, and as humans we find estimating really hard. We are just not very good at it.

This article considers what businesses really need, why humans are bad at estimating, and what we can do instead which is spend less effort refining estimates and more effort reducing uncertainty through discovery, feedback, measurement, and incremental delivery.

What businesses want

Risk reduction

Estimating does not reduce risk.

If an engineering teams estimates "this work could take 8 weeks" the technical risk from unkowns remains:

• Hidden dependencies
• Load and performance issues
• Requirement changes
• Unknown API behaviour

What really reduces risk is work to shed light on the unknowns.

• prototyping
• spikes
• architecture reviews
• small releases
• early testing
• frequent feedback

An estimate might increase risk as it can create false confidence.

Your colleagues outside engineering will interpret any carefully expressed estimate as a delivery date. Based on this, they will schedule related work. If your work is then not delivered based on the estimate, engineering will be seen to be at fault.

Decision-making information

One area where estimates may be useful is in ranking feature options to help decide whether a business should invest itime and effort in their implementation.

A business often needs to decide between implementing a number of options:

Attempting to put an exact number against each feature is largely pointless, as they will often be wrong. It is the ranking that is useful.

This is only one variable in many that should be used to decide if a feature is to be built. Feature C may require the largest investment but, once deployed, it may deliver significant value, and provide to customers something that no one else does.

Predictability

Many organizations such as Amazon and Spoitfy forecast based on historical delivery data, rather than relying on estimates.

This should be more predictable as the historic data reflects an actual outcome and not an educated guess.

Accountability

Software development is not simply execution. It is not simply "doing the typing."

Software development is a highly collaborative endeavour of knowledge discovery and any estimate will reflect what is only known at the time.

Accountability rests on:

• transparency
• communication
• explaining uncertainty
• escalating risks early

If your organisation uses estimates to point the finger ("you missed the deadline"), you will see that your engineers add amounts to their estimates to given themselves room for the "unknown unknowns". This is a rationale response to being accused of missing a deadline when estimates are known to be inaccurate in the face of the unknowable in both future business operations, and uncovered technical and business requirements.

Why estimating is hard for humans

If you are using estimates, this is why it is difficult.

Underestimate complexity

When estimating something, humans see the surface of the problem. Not the hidden nuance and detail. In planning, we assume the "everything works path" will happen. There are, of course unknowns that take us away from that path.

When we estimate a day to update user login, we think in terms of that feature as a single unit, not in terms of the reality which might be support for username/password, single sign-on, and on-off authentication via a third-party such as Facebook or Apple.

A better approach would be to take a look at the code to be updated first and then issue an estimate with all the necessary "unknown unknown" caveats.

Narratives over probabilities

Humans prefer a clean story ("this will take a day") rather than a distribution (there is a 40% chance it takes three days). The probability is more accurate but they make people feel uncomfortable as they articulate there is a chance something may not happen. People wonder what they should do if the work takes three days.

Communicating "this will take a day" is too emphatic. Especially without having looked at the code first.

Once an estimate is issued, other initiatives are put into place that depend on the deadline being met. If it is not, colleagues become frustrated: "Why is the work delayed?".

Even though the timeline is an estimate it has been communicated as if it were a certainty.

Emotional pressure in estimating

People fear looking slow and disappointing others, and so they might give the estimate they think people want, not the estimate that is true. The risk is higher such an estimate is missed due to the items below.

This can be a driver for being over emphatic. When an estimate is requested it can be better to not respond immediately, and check the code first to more clearly understand the reality of any change.

If you have given an estimate of 3 months and the business has stated that the work must be complete and deployed within 4 weeks, an estimate was not really needed.

What this does show is the disparity between engineering and the rest of the business. A positive way forward is to scope the work so that something can be delivered in 4 weeks. You do have to work hard in this case to ensure additional pieces of work are not snuck in "just in case". Such additions risk derailing the delivery of the 4 week work.

Blind to invisible work

Software engineering is a highly complex endeavour requiring extensive collaboration that is built on coordination, waiting, approvals, quality checks, integration, and rework and recovery. Across fields people often overlook the hidden aspects when estimating.

Collaboration entails a lot of waiting. During software development, questions are raised that were unknown at the start. Development on a piece of work can stall while an answer is sought. This waiting can soon cause your delivery to blow past any estimate.

This is one reason why delivering the smallest unit possible is a good strategy for the business. Less work leads to fewer questions so that the engineer has a higher likelihood of being able to work autonomously, without stalling, waiting for clarification.

Familiarity bias

Things that feel familiar ("I have done this before") get mentally discounted, even if the context is different, the challenge is unique, and the difficulty is higher.

You estimate one day because you have looked at user login before. However, the issue this time, is that user login is unexpectedly timing out when they use a mobile.

The mobile context here is different to that of desktop: the difficulty is higher because recreating the issue may require some time.

Considering the best case

Humans select the fastest time they have ever done something, not the average time. This is why estimates move towards optimism.

In the past you may have estimated a day for a task but delivered it in half a day.

This is because, this time around, you were able to focus, without having to attend to a production issue or cover for a sick colleague or attend a meeting.

You will associate half a day for such work in the future, overlooking that interruptions are a lot more disruptive.

Underestimating error cost

To err is human. People forget that mistakes create rework, delays, coordination overload, and an impact that cascades. With mistakes, the elapsed time to fix is often larger than the cost of doing.

Fixing an issue requires first effort to understand what the issue is, and where in the codebase a suitable solution can be placed.

Understanding the issue is a bit like going to see your family doctor. They determine what the issue might be by examing you (observation), and by asking you questions.

When applied to technology, such an investigation takes a variable amount of time depending on the issue. It is hard to know how long such an investigation may take.

Once you have identified what the issue is, you need to settle on a remedy, just as a doctor might when prescribing a medicine based on medical guidance and their experience.

Remediating the issue will take time, and it is variable depending on what solution is being used.

The two main tasks - investigate and remediate - both take a variable amount of time as they are highly context dependent and the implications of what that context is for the work are not fully understood until the work gets to that point. This is one reason why estimating defect fixing is a challenge: we are guessing about the future.

Ignoring interruptions

Humans assume continuous focus. Interrupting a software engineer adds 20 minutes of recovery time to a task while the person rebuilds their mental model of what they are doing. If priorities are constantly changing, this produces enough interruptions that engineers spend a lot of time switching tasks only to be switched to another when the priorities change again. Very little forward progress is made.

Interruptions are inevitable. Others want your input so that they can progress their own tasks. This is fine. But to achieve the necessary focus for a complex issue, engineers may have to go "off grid" by disconnecting from electronic communication for a while.

Assuming stable conditions

We assume future conditions match present conditions but dependencies change and slip, requirements evolve, people get sick, systems behave differently under load. In business, change is a constant.

Unknown unknowns can derail any estimate. Therefore, all estimates should be delivered with an error bar, or probability. The organisation you work for must appreciate that an estimate is just that. It is not a guarantee. Not a promise.

Any planning around delivery of a work item with an estimate attached must also plan for the work not being delivered at the estimated time. Planning should assume two paths: the estimate met path, and the estimate missed path.

We are poor at compounding effects

Small delays accumulate that are difficult to account for when estimating. Small errors multiply, and uncertainties stack up that require waiting to resolve.

If you need to get input from four colleagues and each takes an hour to get back to you, you will be waiting a morning before you can make any realistic progress.

When estimating a task, we tend to think of working in isolation on the task: the "me time" to complete an activity. The collaboration and resulting waiting is the overhead that allows the "me time" to take place.

Conclusion

The main lesson is that estimates are often mistaken for certainty when they are really just guesses about an uncertain future. Businesses typically want reduced risk, predictability, and accountability, but these come from understanding the work, exposing unknowns, and measuring actual outcomes, not from asking people to predict them.

Estimating is difficult for humans as we under play key points such as complexity. The best advice is to spend less effort refining estimates and more effort reducing uncertainty through discovery, feedback, measurement, and incremental delivery.

Read next: Software Delivery Constraints and Pipeline Throughput
Modern software delivery is not just coding. It is a seven‑stage, 32‑task pipeline. Speed gains from AI only matter when the pipeline is understood and has capacity end-to-end.

Related Articles

• Measuring Reliability in the Age of AI
• Bias, Metrics and Technical Debt
• The Big AI Gains Come From Teams, Not Individuals
• The Missing Structure Agile Cannot Fix
• When Code Is Cheap, Judgement Matters More