By 2026, most Agile practitioners have plenty of scar tissue when it comes to estimating and planning.
I hear the same stories over and over again.
Estimates treated as promises, plans turned into contracts, teams punished for being wrong rather than rewarded for learning.
Given experiences like those, it's understandable that many teams decide the solution is to eliminate estimating and planning altogether.
I think that's a mistake.
Estimating and planning still matter.
Not because the future is predictable, but because it isn't.
They matter because teams and organizations still have to make decisions about what to work on, what delay, and what risks they're willing to accept.
In this video, I want to explain why I believe that, And what estimating planning look like when they are used responsibly.
Anytime you choose one piece of work over another, you're estimating.
You're estimated cost, value, risk, or effort, even if you never put a number on it.
I've worked with teams who proudly told me they don't estimate.
But then I watched them make decisions based on unspoken assumptions about size and difficulty.
The estimates were still there.
They were just invisible and unexamined.
And in my experience, that's worse.
The real choice isn't whether to estimate, it's whether estimates are explicit or implicit.
One of the most damaging beliefs in agile is that estimates exist to be accurate.
That framing turns every estimate into a test and every miss into failure.
In healthy agile environments, estimates exists to support decisions.
Is this worth starting?
Should we do this now or later?
What are we trading off?
So a better question than is this estimate accurate is, Is this estimate good enough to support the decision we're making?
When teams ask that question, estimation becomes far less stressful and far more useful.
I often hear people say estimates are always wrong.
They're usually frustrated, and they're not entirely wrong, but being wrong isn't the real problem.
Estimates are hypotheses.
Reality supplies the data.
I'm reminded of this every time I run a training class.
If it's a course I've taught before, I can estimate almost perfectly how long it will take me to prepare for the class, But if it's a new class,
new slides, different exercises, and new discussion prompts?
When my estimate is off, it doesn't mean estimating was pointless.
It tells me exactly what I didn't yet know.
That's how estimation works on agile teams, too.
The failure isn't being wrong.
Failure is treating estimates as promises and punishing teams when reality turns out to be more complex.
Planning is often portrayed as the opposite of agility.
In practice, the OPPOSITE is true.
Good planning aligns assumptions and intent.
It gives teams a shared starting point so they can adapt quickly when things change.
What actually reduces adaptability is planning too far ahead and over-committing to uncertain work.
I like to think of planning the way I think about planning a hike.
You don't plan because you expect the weather to behave.
Flow metrics have added valuable grounding to agile work.
They tell us how work has flowed in the past, but they struggle with novelty.
Whenever work is new or risky, historical averages become less reliable.
That's where estimation still helps.
Not to predict precisely, But to reason about what might be different this time.
Rather than choosing sides, teams are better served using both.
Flow metrics for grounding, estimation when thinking through new work.
One of the surprises I've seen is that removing planning often increases pressure on teams.
Without boundaries, work expands.
Priorities shift constantly.
Overcommitment becomes invisible.
Lightweight planning creates focus and boundaries.
It gives teams a chance at sustainable pace.
Planning isn't bureaucracy.
it's one of ways teams protect themselves from chaos.
Before estimating or planning, I encourage teams to pause and ask three questions.
What decision does this support?
What happens if we're wrong?
And who will use this information and how?
If those questions don't have clear answers, the problem usually isn't how the team is estimatin.
It's why they're estimati.
Uncertainty isn't a flaw in Agile systems.
It's the reality those systems are designed to handle.
Estimating and planning don't eliminate uncertainty.
They help teams navigate it together.
Thanks for watching.