Your Estimation Model Is Lying to You (And What to Use Instead)

I watched a team burn six weeks on a feature nobody was going to use.

Not because the engineers were slow. Not because the requirements were unclear at the outset. They were perfectly clear. The team executed the plan flawlessly—the code was clean, the testing was solid, and the merge conflicts were minimal. By every metric we'd measured over the past five years, this was a successful delivery.

But we delivered the wrong thing.

Thanks for reading! Subscribe for free to receive new posts and support our work.

When I dug into what happened, the real problem wasn't in the execution phase at all. It was hidden earlier, in the estimation phase. The team had estimated theworkcorrectly. What they hadn't estimated was thedecision cost. By the time we shipped, the market had moved, the customer's business had changed, and what made sense in week one made no sense in week six.

This is the pattern I've been seeing across every engagement we work with at InTech Ideas. The bottleneck isn't velocity anymore. It hasn't been for years. The bottleneck is decision velocity—the speed at which teams can commit to what matters and adjust when they're wrong.

And our estimation models are built for a world that no longer exists.

The Velocity Myth (and Why AI Made It Worse)

In a previous article, I wrote about the Scrum problem—how the framework optimized teams for predictable, repeatable work at a time when software was becoming less predictable and less repeatable. Story points and velocity chartsfit that era perfectly. They answered a simple question: How much can a team build per sprint?

But that question assumed something critical: that \"building\" was the constraint.

Five years ago, when a senior engineer spent three days debugging a database query, the constraint was real. Building took time, and you could measure it. You could estimate it. You could plan around it. The math worked.

Then the tools changed.

I havejunior engineerson our team who can ship features in a day that would have taken a senior engineer a week in 2015. Not because those junior engineers got better. Because GitHub Copilot, Claude, and thefeedback loopof modern AI tooling compressed the actual coding work into hours instead of days.

We won the wrong race.

The teams I work with now can estimate thebuild phasewith remarkable accuracy. What they can't estimate is thedecision phase—the time between when you think you know what to build and when you actually know what to build. And because the industry's measurement systems haven't caught up to this shift, teams are flying blind at the exact moment their fate is being decided.

I watched one product team spend two weeks in grooming sessions before a single line of code was written. The estimation was tight on the coding. The decision-making was glacial. In the end, they built the right solution to the wrong problem, and when reality collided with their plan, the whole timeline compressed into chaos.

The real wastewasn't in the build phase. It was in the decision phase that nobody was measuring.

Where Decisions Become Expensive

Here's what changed in the last few years, and why your current estimation model doesn't account for it:

The decision cost scales with team size.Two engineers can decide in an hour. Eight engineers in a standby state, waiting for that decision, cost a thousand dollars. A hundred-person organization waiting for a decision costs ten thousand. We keep building estimation models that ignore this math entirely.

The decision cost compounds over time.In 2020, if you estimated wrong, you had time to course-correct. The cycle time was slow enough that pivoting was survivable. Now, a decision made in week one that's wrong by week three creates schedule pressure that the entire team feels. But we estimate as if the decisions are costless, as if changing your mind mid-flight has no friction.

The decision cost is invisible until it's catastrophic.

A delayed deployment shows up on a dashboard. A delayed decision gets absorbed into the culture and called “thoroughness.”

I was in a meeting with a CTO last month who told me they'd decided to rebuild their entire API layer. The team had estimated the work: four months, two engineers. The real cost was invisible: six months of product team paralysis because nobody wanted to build features on top of unstable infrastructure. The estimation model only counted the first number.

The interesting tension—and this is where I need you to think differently—is that AI has made thebuildingpart faster whilethedecidingparthas stayed exactly the same speed. Maybe it's gotten slower because the ease of building has given teams more options to deliberate about.

We have the capacity to build almost anything now. We're just not any better at deciding what we should build.

The New Unit of Estimation: Decision Points

Skip talked a few weeks back aboutthe org structure gap—how decision authority gets diffused across layers, how unclear ownership prevents product teams from moving at the speed they could. That wasn't just an organizational problem. It was an estimation problem. Because every layer that has to weigh in on a decision adds friction, and friction costs time, and we weren't measuring that time.

I've started thinking about estimation differently: not in terms of story points or velocity, but in terms ofdecision points.

A decision point is a commitment: a moment where the team says, \"This is what we're building, these are our assumptions, and here's how we'll know if we're right.\" It's not a requirement. It's not a design. It's the smallest testable unit of direction.

I worked with a media platform that was trying to estimate a recommendation engine rebuild. The old model said: \"Five months, four engineers.\" But when we mapped the decision points, the real picture emerged:

Decision one:Do we rebuild the algorithm, or do we retrain the existing one? (One week of data analysis, stakeholder alignment.)

Decision two:If we rebuild, do we prioritize accuracy or latency? (These trade-offs. Different teams care about different outcomes.)

Decision three:How do we measure success? (Not a metric question—a question about what the business actually values.)

Only after those three decisions were locked did the estimation of thebuildmake sense. And the build? With the decisions clear, two engineers knocked it out in six weeks. The estimation wasn't wrong. The measurement system was incomplete.

Here's what changed: we stopped estimating the work and started estimating the clarity required to do the work well .

Telemetry for a New Bottleneck

If you're going to measure something, you have to count it.

Traditional velocity metrics count deployments, story points, or bugs shipped. They measure the output of thebuildphase. But if the bottleneck has moved to thedecisionphase, your telemetry is measuring the wrong thing. You're optimizing for the wrong constraint.

At InTech Ideas, we've started tracking different signals — not as a new framework, but because the old metrics were useless for the actual constraint:

Days from the decision point to the code being written.Not \"design approval to deployment.\" Just the gap between when the team commits to what they're building and when the work actually starts. If that number is more than three days, something in your decision-making is broken.

Number of revisions to the core assumption.If a product team starts building, and two weeks in, the founding assumption changes, that's a signal that the decision point wasn't as solid as you thought. We count these. Not to blame teams, but to see where the decision process is failing.

Stakeholder alignment velocity.How many decisions can a team make andcommit toin a week? This varies wildly by org structure, by clarity of strategy, by how much context people have. But it's measurable. And it predicts whether a product will ship on time more reliably than story points ever have.

Time in decision space vs. time in build space.This is the ratio that matters. For a healthy team delivering complex products, I want to see maybe 30% decision time and 70% build time. I've seen teams where that ratio is inverted—30% build, 70% in meetings deciding what to build. That ratio tells you whether your org can scale.

The teams that track these metrics stop being surprised by schedule slips. They see them coming. They understand why a feature that \"should only take two weeks\" is actually a four-week problem (because decision-making, not building, is the constraint).

What This Means for Your Next Estimate

This isn't about replacing story points with some new system. It's about being honest about what you're actually estimating.

The next time your team sits down to plan a feature, try this: separate the estimation into two phases.

Phase one:How many decision points need to be locked before the build phase can start? For each decision, estimate the time required for the team to gather information, consider options, and make a call. This is where the real risk lives.

Phase two:Once decisions are locked, how long does the build take? This should be relatively tight now, because the ambiguity is gone.

Sum them, and that's your real estimate.

I've seen this simple frame cut feature timelines in half, not because engineers got faster, but because teams stopped building the wrong thing. We were spending weeks in execution to learn something we could havelearned in days, if we'd been honest about what we didn't know.

The Glimpse Ahead

There's a cost to revisiting decisions. I mean a real cost—it creates entropy in a team, it damages credibility, it makes people hesitant to commit to a new direction.

This is going to be the next article: what happens when you lock a decision point, but reality tells you it was wrong? How do you change course without shattering the team's confidence in the planning process itself?

It's the difference between a team that adapts and a team that just thrashes.

If this resonated, subscribe. We're writing about what's actually changing in software delivery—no hype, no hand-waving, just what we're seeing with real teams on real products.