Most teams estimate because they’re trying to answer two reasonable business questions:
- When will this be done?
- How much will this cost?
The problem isn’t the questions.
The problem is that estimation is a poor way to answer them.
At Nolte, we don’t estimate effort. We still predict delivery, accurately and consistently, but we do it using real data, not guesses. This post explains why.
I’ve Tried Every Estimation Method
This position didn’t come from theory. It came from experience
Over the years, I’ve led teams using:
- Scrum
- ScrumBan
- T-shirt sizing
- Story points
- Fibonacci sequences
- Planning poker
- Velocity tracking
- Re-estimation cycles
I wanted estimation to work. I invested heavily in it.
What I consistently saw was this:
- Hours spent debating numbers
- Teams optimizing for “safe” estimates
- Stakeholders mistaking precision for certainty
- Misses that still required explanations and renegotiation
No matter the framework or technique, estimation never reliably answered the two questions that actually matter to the business:
- When will this be in market?
- How much will it cost us to get there?
The Core Issue With Estimation
Estimation asks teams to predict the future based on incomplete information.
That creates several structural problems:
- Estimates are guesses, not commitments
- Precision is implied where none exists
- Teams defend numbers instead of outcomes
- Planning time grows while certainty does not
Worse, estimates decay the moment work starts. Requirements evolve, edge cases appear, and priorities shift, all normal parts of building software.
Estimation doesn’t reduce uncertainty.
It hides it behind numbers.
Estimation Creates Planning Theater
In many organizations, estimation becomes a ritual:
- Long planning sessions
- Poker games and debates
- Velocity charts and justifications
- Re-planning when reality diverges
This consumes time, increases stress, and rarely improves delivery outcomes.
From a business perspective, it’s waste.
The Shift That Changed Everything
Eventuall I stopped asking:
“How do we get better at estimating?”
And started asking:
“Why are we estimating at all?”
The breakthrough came when we shifted from forecasting effort to managing flow.
That shift is what ultimately became The Nolte Way.
What We Do Instead
At Nolte, we separate commitment from guesswork.
We do not estimate effort.
We commit based on evidence.
We predict delivery using:
- Historical cycle time
- Team throughput
- Aging work signals
These are observable, measurable, and grounded in how the team actually performs, not how we hope it will perform.
How Prediction Works Without Estimation
Instead of asking “How long will this take?”, we ask:
- What is our average cycle time (how long does all of our work take on average to be completed)?
- How many items does this team reliably deliver per month?
- Where does work tend to age or stall?
Patterns emerge quickly.
Those patterns allow us to:
- set credible delivery expectations
- identify tradeoffs early
- surface risk before it becomes a problem
This creates predictability without false precision.
Why This Is More Predictable
Predictability doesn’t come from better guesses.
It comes from stability and transparency.
By limiting work in progress and measuring flow:
- commitments become credible
- surprises get smaller
- delivery becomes boring, in the best way
Teams stop negotiating estimates and start managing reality.
What This Enables for Clients
- Predictable delivery without rigid scope
- Clear expectations on cost and timing
- Confidence in prioritization and ROI
- Faster feedback from working software
- Fewer surprises
Clients don’t need estimates.
They need trust.
What This Enables for Teams
- No estimation theater
- Fewer clarifying questions
- Clear ownership and flow
- Less rework and context switching
- Reduced leadership bottlenecks
Teams focus on delivering value, not defending numbers.
Isn’t This Just Kanban?
Yes, intentionally.
This approach is grounded in Kanban and modern flow-based delivery practices. It treats software development as a system, not a sequence of promises.
Estimation isn’t inherently bad.
It’s just unnecessary when you manage flow well.
The Bottom Line
We don’t estimate because estimation doesn’t make delivery more predictable.
We predict by:
- observing reality
- managing flow
- committing responsibly
- learning continuously
That’s how we deliver working software that actually impacts the business.