How estimates turn into false promises

Management needs planning.

That’s legitimate.

Teams need direction. Budgets need assumptions. Stakeholders need something predictable. Nobody can run a company, a product, or a project if every question just gets a shrug.

The problem doesn’t start where someone asks for a plan.

The problem starts where an uncertain estimate quietly turns into a promise that sounds solid.

“We just need a rough estimate”

The sentence sounds harmless.

“Just rough.”

“Just for planning.”

“Just so we get a feel for it.”

And then what almost always happens in organizations happens.

The rough estimate keeps traveling.

It shows up in a roadmap. Then in a budget plan. Then in a steering meeting. Then in an expectation. Then in an escalation.

And at some point nobody remembers that the number was born under uncertainty.

“Maybe two weeks, if the assumptions hold” turns into:

“The team committed to two weeks.”

That’s the moment planning breaks down.

Not because management needs planning.

Because uncertainty got stripped out of the plan.

Software development isn’t assembly-line work

The fallacy behind a lot of time estimates is an old one:

Treating software development like deterministic manufacturing.

As if there were a known process. As if there were known steps. As if there were known repeatability. As if you just needed to know the execution speed.

For assembly-line work, that’s often closer to the truth.

When material, process, tooling, and target are known, you can measure throughput. Then planning gets a lot more reliable. Not perfect, but at least observable.

Software development is often something else.

It’s not just execution.

It’s analysis.

It’s modeling.

It’s integration.

It’s debugging.

It’s clarifying domain questions.

It’s reducing risk.

It’s discovering what you didn’t know beforehand.

Especially in existing systems, the real work is rarely just:

“Build feature X.”

It’s more like:

“Find out what feature X even means in this system, which unwritten rules exist, which dependencies get touched, and which assumptions turn out to be wrong.”

That’s not typing speed.

That’s knowledge work under uncertainty.

Experience isn’t an X-ray machine

A particularly popular line:

“You’re senior. You can estimate this.”

Yes.

And no.

Seniority helps.

An experienced developer spots patterns faster. An architect sees dependencies sooner. A tech lead smells risk before it stinks up the daily standup.

But experience isn’t an X-ray machine.

It doesn’t automatically reveal unknown business rules.

It doesn’t automatically reveal hidden side effects.

It doesn’t automatically reveal historical edge cases.

It doesn’t automatically reveal broken test data.

It doesn’t automatically show which piece of legacy is going to fall out of the wall during the first real debugging session.

Experienced people are often more careful with estimates, not because they know less, but because they’ve seen more.

A junior looks at a ticket.

A senior looks at a ticket, three implicit assumptions, two unknown interfaces, a possible permissions issue, missing testability, and a domain question that probably nobody has decided yet.

That’s not uncertainty from weakness.

That’s uncertainty from understanding the system.

Seniority doesn’t mean eliminating uncertainty. Seniority means spotting it earlier.

Research doesn’t call it a gut feeling

Underestimating work is nothing new.

Psychology has a name for it: the planning fallacy. People tend to be more optimistic about future tasks than similar past tasks would justify. The inside view is especially dangerous here: you picture how the work goes ideally, and underestimate interruptions, waiting time, clarifications, mistakes, and dependencies.

In software development, something else gets added on top.

Estimates often come from expert judgment — the assessment of experienced people. That’s not worthless. But it’s vulnerable to optimism, anchoring, social expectations, and confidence intervals that are too narrow.

If a target date is already in the room, the estimate isn’t neutral anymore.

If budget pressure is already in the room, the estimate isn’t neutral anymore.

If someone says beforehand “that’s just a small change,” the estimate isn’t neutral anymore.

At that point, it’s no longer just an estimate.

It’s a negotiation.

And often it’s not even negotiated openly. The number just gets psychologically nudged in the direction people want.

The cone of uncertainty isn’t an excuse

The cone of uncertainty describes a simple, uncomfortable truth:

Early estimates are less certain than later ones.

Not because early estimators are incompetent.

Because information is still missing at the start.

Requirements are still unclear. Interfaces haven’t been tested yet. Risks aren’t visible yet. Business rules aren’t explicit yet. Dependencies haven’t been experienced yet. Technical debt hasn’t been touched yet.

You can still plan during this phase.

But you shouldn’t pretend an early number carries the same weight as a forecast made after several real slices, integrations, and feedback cycles.

An early estimate isn’t the truth.

It’s a snapshot of what is still unknown.

That sounds harsh.

It’s useful, though.

Because once you accept that, you can do something sensible: reduce the uncertainty.

”It’s done when it’s done” is honest but unusable

Sometimes the most honest internal answer is:

“No idea. It’s done when it’s done.”

That’s human.

Especially in a new system. With new business logic. With unfamiliar architecture. With unfamiliar data. With unfamiliar dependencies.

But as an answer, it helps nobody.

Not management. Not the team. Not the customer. Not the plan.

The more professional answer is:

“We don’t have enough system and domain knowledge right now for a solid time estimate. But I can estimate the next steps that would reduce that uncertainty.”

That’s an important distinction.

You’re not refusing to plan.

You’re not planning the unknown outcome.

You’re planning the next step toward understanding.

For example:

• a technical spike
• an analysis of the affected interfaces
• a minimal end-to-end slice
• clarifying business rules with concrete examples
• characterizing existing behavior
• a prototype against real data
• a risk decision before implementation

That’s mature planning.

Not:

“We already know when everything will be done.”

But:

“We know what we need to find out next to plan better.”

When estimates sort people

A small example.

A ticket gets estimated as a team.

A junior says:

“Five days.”

A senior says:

“One day.”

After discussion, the team settles on:

“Two days.”

Then comes the seemingly practical question:

“Who’s doing it?”

And if the answer is:

“The senior, obviously,”

something is broken.

Because at that point, work didn’t get estimated.

People got sorted.

The estimate stops reflecting how complex the team judges the work to be. It becomes a covert pre-assignment.

That has consequences.

The junior doesn’t learn. The senior becomes a bottleneck. Knowledge keeps concentrating. The team gets more dependent on individual people. Complex work always ends up with the same people. Seniors burn out. Juniors stay juniors longer. Self-organization becomes a facade.

In the short term, that looks efficient.

In the long term, you build a system where the most experienced people permanently have to rescue the hardest work, while nobody else gets enough room to grow into it.

That’s not agile planning.

That’s capacity management with a side of blocked learning.

Goodhart is already waiting in Jira

Estimates have another problem.

As soon as a metric becomes a target, behavior around that metric changes.

That’s known as Goodhart’s law:

When a measure becomes a target, it stops being a good measure.

Applied to software:

When estimated hours become the control metric, the system optimizes for estimated hours.

Not for value. Not for learning. Not for quality. Not for reducing risk. Not for real delivery capability.

For the number.

An example:

A developer estimates a ticket at 40 hours.

After 20 hours, it’s done.

What happens now?

In a healthy system, that would be good news.

The work was smaller than expected. There’s new information. The forecast can improve. Maybe the ticket was simpler. Maybe the solution was more elegant. Maybe the estimate was too conservative. Maybe risk got reduced early.

In a broken system, a different impulse takes over:

“Better log 40 hours, or the next estimate looks bad.”

Or:

“If I honestly log 20 hours, next time they’ll expect 20 again.”

Or:

“If I finish faster, I just get more work.”

Or:

“If we deliver under plan, the plan just gets more aggressive next time.”

That turns the estimate into a self-fulfilling prophecy.

Not because developers are lazy.

Because the system creates the wrong incentives.

Anyone who uses estimates as a personal performance metric isn’t protecting planning.

They’re destroying the data that could actually improve planning.

At that point, logged hours aren’t an observation anymore.

They’re a defense.

False precision feels better than uncertainty

Why does this happen anyway?

Because false precision is reassuring.

“This takes 17 days” sounds better than:

“Between 8 and 30 days, depending on whether the interface does what’s documented.”

A single number fits better into a roadmap.

A single number fits better into a budget.

A single number fits better into a slide deck.

A single number fits better into a conversation with people who don’t want to hear about uncertainty.

But a single number isn’t automatically more accurate.

It’s just easier to consume.

And that’s exactly what makes it dangerous.

Because uncertainty doesn’t disappear just because you delete it from the slide.

It shows up again later.

As a delay. As a bug. As rework. As an escalation. As a weekend of work. As “why didn’t you tell us this earlier?”

The answer is often:

We did. Just not in a form that was allowed into the plan.

What actually helps?

The alternative to bad time estimates isn’t working without a plan.

The alternative is better planning.

And better planning starts by actively reducing uncertainty instead of hiding it.

1. Cut small work packages

The bigger a ticket, the more unknown risk dominates it.

If a ticket looks like it’ll take more than roughly three development days, that’s not a law of nature, but it is a warning sign.

Maybe the ticket is too big. Maybe it contains several decisions. Maybe analysis and implementation are mixed together. Maybe a concrete business example is missing. Maybe it depends on an unknown interface. Maybe it’s really a project in disguise.

Small tickets don’t automatically make everything easy.

But they make deviations smaller.

And small deviations are plannable.

2. Estimate complexity, not hours

Relative complexity is often more honest than estimates in hours.

Not:

“That takes 13 hours.”

But:

“That’s small, well understood, and low-risk.”

Or:

“That’s unclear from a business standpoint, technically coupled, and should get broken down first.”

Story points, T-shirt sizes, or similar models aren’t magic.

They only work if nobody secretly translates them back into hours.

The moment “5 points” automatically becomes “3 days,” you’ve just invented a new currency for the same old false precision.

3. Make uncertainty explicit

A usable estimate isn’t just a number.

It needs context.

For example:

• optimistic
• likely
• pessimistic
• biggest assumption
• biggest risk
• open decision
• dependency
• next thing to learn

A statement like:

“Probably two to four days, but only if the existing API delivers the expected data. The biggest risk is the permissions logic.”

is far more valuable for planning than:

“Three days.”

Even though it’s less comfortable.

4. Reduce risk first, then fix dates

If an effort is large, unclear, or new from a business perspective, don’t estimate the whole implementation right away.

Attack the riskiest part first.

Not the easiest one.

Not the prettiest one.

Not the part that looks good in a demo.

The part that puts the plan most at risk.

That could be an interface. A permissions model. A data model. A migration. A business edge case. A performance risk. A deployment path. A testability problem.

Planning confidence comes from shrinking the biggest unknown risks.

Not from staring at a number for longer.

5. Use historical data

If you want to improve planning, you need real observation.

Not as a control tool against individual people.

As an outside perspective for the team.

How long do similar tickets actually take? How often do external dependencies block work? How long is our real cycle time? How many items do we consistently ship? Which types of work regularly blow up? Where does rework come from? Where do tickets sit and wait? Where is decision-making missing?

That’s the point where planning grows up.

Away from:

“How long do you think this will take?”

Toward:

“What do our real cycle times show for similar work?“

6. Use PERT as a thinking tool, not a truth machine

PERT and three-point estimates can help make uncertainty visible:

• optimistic
• likely
• pessimistic

That’s better than a single number.

But even PERT goes wrong if, at the end, it still spits out one seemingly exact number that then gets treated as a commitment.

PERT helps most when many independent tasks can average out statistically.

For a few large, coupled risks, no formula saves you.

Then you need smaller slices instead.

Planning confidence is risk management

Planning confidence doesn’t come from pushing people harder for numbers they can’t seriously know yet.

It comes from structuring work so uncertainty becomes visible earlier and smaller.

That means:

• smaller tickets
• real business examples
• early technical spikes
• clear boundaries
• fast feedback cycles
• visible risks
• honest ranges
• historical cycle times
• regularly updated forecasts

That’s less comfortable than a single number.

But a lot more useful.

The better sentence

The question shouldn’t be:

“How long will this take?”

At least not as the first question.

The better questions are:

“What do we actually know for sure?” “What’s still an assumption?” “What’s the biggest risk?” “How do we cut it smaller?” “What can we learn this week?” “What real observation would improve our forecast?”

Because an estimate isn’t a delivery date.

It’s a statement about the current state of our uncertainty.

Management needs planning.

But planning needs honest uncertainty, not false precision.

And anyone who genuinely wants planning confidence doesn’t ask for better fantasy numbers.

They build a system that makes risk visible earlier.