Estimation Is for Deciding, Not Predicting

Part 2 in the Real Understanding vs Buzzwords series.

You have probably sat in this meeting.

A Product Backlog item comes up. The discussion jumps straight to effort.

How big is it? How complex is it? How many points?

Nobody asks the quieter, more important question.

Is this worth doing?

That is not a process failure. It is a thinking failure.

In the previous post we looked at how people misuse velocity to create false certainty. Estimation suffers from a similar problem, for a different reason.

Why estimation becomes a problem

People usually treat estimation as a sizing exercise. We estimate:

• how long something will take
• how hard it will be
• how much effort is involved

Those questions sound reasonable. They are also incomplete.

They assume the work is already valuable. They assume the decision to do it has already been made.

In many teams, estimation happens after value has quietly been taken for granted.

The litmus test: effort vs worth

The question

Ask a Product Owner, Scrum Master or delivery lead: "When the team estimates, what are you expecting the estimate to tell you?"

Then listen carefully.

To surface the thinking faster, follow up with: "What decision are you expecting to make based on that?"

The shallow understanding answer

Common responses sound like this:

• Effort
• Complexity
• Size
• Time
• Story points

Sometimes you hear:

• We estimate so we know how long it will take.
• We estimate how much we can plan into a Sprint.
• We estimate to forecast delivery.
• We estimate so stakeholders know what is coming.
• We estimate so the team can commit.

All of these reveal the same expectation: that estimation exists to turn uncertainty into commitment. They frame estimation as a delivery support activity, not a decision-making tool.

Why this misses the point

When estimation is only about effort, a few things happen quietly.

Value is assumed, not explored. Trade-offs are skipped. Risk is discussed late, if at all.

Estimation becomes a gate you pass through, not a conversation you learn from.

Teams get very good at answering "How hard is this?" and very bad at answering "Should we do this at all?"

That is how backlogs fill up with well-estimated work that delivers very little.

The genuine understanding answer

People with a deeper understanding answer differently. They might say:

• We estimate to explore options.
• We estimate to understand risk and uncertainty.
• We estimate to decide whether something is worth doing.
• Sometimes the estimate tells us not to build it at all.
• We estimate to align expectations, so we can negotiate trade-offs and collaborate on value.

They usually make this explicit:

• Effort only matters in relation to value.
• Estimation without value is just sizing.
• The goal is better decisions, not better predictions.

At this level, estimation stops being a commitment mechanism. It becomes a thinking tool.

Why this matters

When teams estimate effort in isolation, they optimise delivery. When teams estimate in service of value, they optimise outcomes.

The shift is subtle but important. From "Can we deliver this?" to "Is this the best thing to do next?"

Estimation stops defending plans and starts supporting choices.

Making it real

Shallow estimation thinking sounds like this:

"This is an eight-point story, so we'll need to plan it carefully."

Better estimation thinking sounds like this:

"This looks expensive relative to the value we expect, and we're making assumptions. What are we actually unsure about? Is there a smaller way to test those assumptions and get feedback sooner? Is it small enough to justify spending another cycle of time and money on it? And if we don't do this now, what really changes?"

Same work. Very different decision.

The essence

One distinction reveals everything. Effort versus worth.

Effort tells you how hard something might be. Worth tells you whether it deserves the effort at all.

Estimation that ignores worth becomes busy work. Estimation that explores worth enables judgement.

What to watch for

Red flags. They may be missing the point if they treat estimation as:

• just about points
• required before the value discussion
• a prerequisite for prioritisation
• about accuracy
• something teams should get better at over time

Green flags. They understand it if they talk about estimation as:

• a way to compare options
• a trigger for value conversations
• a tool for exposing assumptions
• a means to decide, not predict
• something that sometimes leads to not doing the work

One last thing

If estimation in your organisation feels heavy, slow or political, that is not because estimation is broken. It is because value is being skipped.

Start with one question. If we don't do this now, what really changes?

Weighing effort against value is at the heart of product ownership, and we spend real time on it in our Professional Scrum Product Owner course.