Agile estimation often feels broken. But maybe it is not the technique. It is the mindset behind it.
Ever been told "You have to use story points"? Or "That's just how Agile works"? What if the real problem is not the tool but the thinking behind it?
"That's how Agile works…"
Not long ago a team told us their agile coach insisted:
"Everything must be estimated in T-shirt sizes."
No explanation. No reason. Just a rule.
This is not rare. Teams are often told, incorrectly:
- "You must use story points."
- "Always estimate with T-shirt sizes."
- "You don't need to estimate at all."
Here is the truth:
- Agile does not require story points.
- Scrum does not prescribe how to estimate.
- There is no one right way to do it.
You can estimate in story points, hours, T-shirt sizes or relative sizes, or skip it entirely. The method a team uses usually depends on its environment and experience.
Some approaches support better conversations than others. Relative sizing, for example, should help a team focus on complexity and uncertainty. But that only happens when it is used to explore, not to control.
Estimating in hours tends to create pressure, false accuracy and a focus on output instead of value. It also invites Parkinson's Law: work expands to fill the time available, which makes teams slower without improving outcomes.
What matters most is the mindset.
Estimation should support conversation and shared understanding. It can help a team make decisions and set expectations, as long as everyone remembers that every estimate is a forecast, not a commitment.
Estimation isn't about being right. It's about learning and making better decisions.
Estimation should spark conversations, not control people
Too often estimation turns into a game of fake certainty.
The questions worth asking are:
- What is the need?
- What is the value?
- Is this small enough to deliver quickly?
- What might go wrong?
Estimation should invite collaboration, not silent commitment. And it should help you check whether something is valuable, not just how much effort it takes.
Estimating with a pack of cards
We use a simple experiment in workshops.
The setup:
- Teams of five.
- Each team gets a deck of cards.
- We secretly remove one card.
- They estimate how long it will take to find the missing one.
They guess. We time it. We record it. We repeat.
What happens? At first they are way off. Then they improve. But they are never exact.
Even with a simple task the uncertainty does not disappear. That is the lesson.
The cone of uncertainty
It is not about when you estimate. It is about how much uncertainty exists when you do.
Imagine arranging to meet someone:
- At the local shop at 10am? You arrive five minutes early.
- At head office in another city? Thirty minutes before.
- In another country? You arrive the day before.
More complexity means more variability. You start thinking in ranges, not fixed answers.
That is the cone of uncertainty. The earlier you estimate, the wider the range. Over time your guesses improve. But they are still guesses.
Even flow-based tools such as Monte Carlo simulation work in probabilities, not promises.
Forecasting is not about being right. It is about being transparent, so you can have better conversations.
Should you stop estimating?
Not necessarily. But stop pretending estimates are facts.
What helps:
- Experience shrinks the range.
- Data improves the odds.
- Conversation creates alignment.
Whether you use story points, T-shirt sizes or nothing at all, make sure your estimates help your team think.
Bring this mindset to your team
The card experiment shows how uncertain even a simple task can be. Estimates are not about control. They are about conversation and learning.
Ask your team:
- Are we trying to be accurate, or trying to understand?
- Do our estimates reflect uncertainty, or just effort?
- Are we using estimation to improve outcomes, or just to track delivery?
One last thought
Estimation is not about answers. It is about better conversations. And maybe the next conversation your team has about estimation is the one that finally makes it useful again.
Other posts in the series
- Velocity. It's not what you think it is
- Still using velocity? Make it useful again
- Story points vs reality: what estimation really shows
We explore these questions, and the shift from output to outcomes, on our Professional Scrum Product Owner course.
Go deeper
Professional Scrum Product Owner (PSPO)
Put this into practice with the course that covers it in depth.
View the course