Estimation Is for Deciding, Not Predicting
Part 2 in the Real Understanding vs Buzzwords series
You’ve 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’s not a process failure.
It’s a thinking failure.
In the previous post, we looked at how people often misuse velocity to create false certainty. Estimation suffers from a similar problem, but 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’re 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: Estimation. 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.
If you want 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’ll 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’s coming
- We estimate so the team can commit
All of these answers 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’s 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’ll 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 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
Weighing effort against value is at the heart of Product Ownership. We spend real time on it in our Professional Scrum Product Owner course.
One Last Thing
If estimation in your organisation feels heavy, slow, or political, that’s not because estimation is broken.
It’s because value is being skipped.
Start with one question.
If we don’t do this now, what really changes?