Why Do Our Estimates Suck? (It's Not Your Team's Fault)

October 29, 2026

This is one of the videos in my Agile-ish series: the good parts of agile, minus the ceremony.

Shameless plug: Want to run the 10-minute check from this post on your own Azure DevOps or GitHub data? Honest Cheetah does the throughput, forecasting, and aging-work math for you. It measures the system, not the people.

▶ Watch this video on YouTube (opens in a new tab)

Here's a question I hear all the time from scrum masters, team leads, and managers: why do our estimates suck?

The team's smart. They take it seriously. They spend real time on it every single sprint. And the dates are still wrong, and the boss is still grumpy.

So what's actually going on here?

TL;DR

Your estimates miss for normal reasons: hidden complexity, unknown unknowns, moving requirements, and interruptions. That's software, not a character flaw.
Even good estimates fall apart when you chain them together. Ten items at 75% confidence each is about a 6% plan.
If your company needs estimates, there are four real ways to make them hurt less.
But first, run the ten-minute mirror: check whether your story points actually predict anything on your team.
There's another way to run a project. Count what you finish, forecast from that, and watch your aging work.

Bump, Bump, Bump

Weirdly, this whole thing reminds me of the very beginning of Winnie the Pooh, the original 1926 book. Pooh comes down the stairs behind Christopher Robin, bump, bump, bump, on the back of his head. And as far as Pooh knows, that's just how you come down stairs. He's sure there's another way, if only he could stop bumping for a moment and think of it.

Hang on to that one. We're coming back to it.

Your Team Isn't Bad at This

Let's start with what this usually looks like on a real team.

Careful estimates. Your team takes estimating really seriously. They break the work down, they talk it through, and they argue about whether something's a three or a five. They really do mean well.

Missed dates anyway. And then the dates slip anyway. Not by a little, either. That thing that was supposed to take two weeks somehow takes five.

A little less trust every time. Every miss costs you a little credibility with your boss and your stakeholders. So next time, everybody pads the numbers, or argues longer, or basically both.

So is the problem that your team is just bad at estimating? I really don't think so.

Why Estimates Miss

Let's talk about why estimates miss, because it's almost never laziness or incompetence.

Hidden complexity. That thing looked like a quick change, right up until you opened the code and found out it touches six other things.
Unknown unknowns. Not the risks you wrote down. The ones nobody even knew to ask about.
Moving target. The customer sees the first version and goes, "oh, actually, that's not quite what I meant." Which is totally normal, by the way.
Interruptions. Production support, an urgent bug, somebody's out sick, a surprise meeting with the VP. None of that was in the estimate.

Here's the thing: every one of those is normal. That's just what software development is like.

The Math Nobody Shows You

But there's one more reason, and it's the one that really gets you.

Let's say you're 75% confident in each individual estimate. That's honestly pretty good. One item at 75%? You'd take those odds, right? That's a solid estimate for software.

But here's the catch. The probabilities multiply.

Items in the plan	Confidence per item	All of them on time
1 item	75%	75%
3 items	75%	42%
5 items	75%	24%
10 items	75%	5.6%

Three items is 0.75 times 0.75 times 0.75, and now you're at 42%. Five items, 24%. And ten items, which is the size of a pretty normal release? About five and a half percent.

Every single estimate was good. And the plan as a whole loses nineteen times out of twenty.

Now I'm simplifying a little, since real items aren't perfectly independent. But it's good enough for right now. Chained estimates fall apart fast.

So your team did everything right. They estimated carefully, and they were pretty confident on every single item. And the plan they handed your boss had about a six percent chance of landing on time.

Ten good estimates. A six percent plan.

OK, So Let's Make Them Better

I'm not going to tell you estimates are doomed and then just walk away. If your company needs estimates, here's how to make them a lot less painful.

Make the items smaller. Small items have less room for hidden complexity, and when they do miss, they miss by days instead of weeks.
Compare to work you already finished. Stop guessing from scratch. Look at similar work you already did and how long it actually took. Your history is a way better estimator than your optimism.
Give a range, not a date. "Probably three weeks, almost certainly within five." That's just more honest, and people can actually plan around it.
Re-forecast every week. An estimate is a snapshot, not a promise. Update it as you learn stuff and nobody gets blindsided at the end.

Those will genuinely help. But there's a bigger question hiding underneath all of this.

Do Your Estimates Actually Predict Anything?

Now I know what you're going to say. "Ben, we need the estimates. The business needs dates." And that's fair. Full disclosure: I taught story points for years, so I get it.

But here's the question nobody ever asks: does all that estimating actually make your forecasts any better?

Not in theory. On your team, with your data.

Because you can check. And it takes about ten minutes.

The Ten-Minute Mirror

Here's the experiment. You don't have to believe me. You just have to look at your own data.

Grab your history. Open up whatever tool you use (Jira, Azure DevOps, GitHub, whatever) and pull up your last ten or so sprints.
Count the items. For each sprint, just count how many items got to done. Not the points. Just the count.
Compare the wobble. Put that count next to your velocity. If the count bounces around about as much as the points do, then the points aren't telling you anything the count didn't already know.
Check your fives. Look at how long your fives actually took, compared to your threes. On a lot of teams, those overlap way more than you'd expect. Which basically means the sizing isn't predicting much.

And if your points do predict something? Great. Keep them. That's the whole point of looking instead of arguing.

Who Cares If Your Estimates Suck?

So here's where I land, and I'm going to say it in the most annoying way possible.

Who cares if your estimates suck? Just do the work, and watch what's actually happening.

OK, Let Me Explain That

OK, OK. That was meant to be a little provocative. Let me walk it back just a bit and tell you what I actually mean.

Count what you finish. Instead of predicting how big things are, just count how many things you finish each week. That's called throughput, and you're probably already capturing it without even knowing.

Forecast from the count. Then you forecast from that count. Something like "85% likely we're done by the fifteenth." No estimation meeting required.

Watch your aging work. And here's the part people miss: watch how long each item has been in progress. If something's been open way longer than your normal work, it's in trouble. And you know that today, not at the end of the sprint.

Put another way: the estimate was always supposed to tell you whether you're in trouble. Aging work just tells you directly.

Two Ways to Run a Project

Let's put these two approaches side by side.

Estimate first is what most teams do today. You guess the size of everything before you start, which is exactly when you know the least about it. Then you find out you're late at the end of the sprint, or the end of the release, when it's too late to do much about it. And then everybody argues about why the estimate was wrong. Which, as far as I can tell, has never shipped a single feature.

Watch the work goes like this. You count what actually finishes. That's a fact, not a guess. You spot items that are aging past your normal range while there's still time to swarm on them, split them, or cut scope. And you fix problems while they're small, instead of explaining them after they're big.

Same team. Same work. One approach finds trouble early, and the other one finds it at the end.

Stop Bumping for a Moment

Remember Pooh, bumping down the stairs, sure there's a better way, if only he could stop for a moment and think of it?

That ten-minute mirror is your moment. You don't have to change anything yet. Just stop bumping long enough to look.

Quick Recap

Your estimates miss for normal reasons. Hidden complexity, unknowns, changing requirements, and interruptions. That's just software, not a character flaw.
Chained estimates fall apart fast. Ten items at 75% is about a 6% plan.
Check whether estimating helps you. Run the ten-minute mirror on your own team. Count items, compare them to points, and see whether all that estimating is buying you anything.
Count, forecast, watch aging work. Try the other way. Count what you finish, forecast from that, and let aging work tell you when something's in trouble.

Shameless Plug

If you want to run that mirror on your own data, I built a tool called Honest Cheetah. It works with Azure DevOps and GitHub, it does the throughput, forecasting, and aging-work math for you, and it'll show you exactly which items are drifting into trouble.

Ran the ten-minute mirror on your team? I'd genuinely like to know what you found. Leave a comment on the video or drop me a line.

-Ben

-- Is your team working really hard but the dates keep slipping? Want help getting off the estimation treadmill and on to something that actually predicts delivery? We can help. Drop us a line at info@benday.com.