Industry Insights, Information, and Developer News
I have a confession: I've spent hundreds of hours of my life in estimation meetings.
Planning poker. T-shirt sizing. Fibonacci sequences. Heated debates about whether something is a 5 or an 8. Entire afternoons lost to the question "but what does a 3 even mean?"
And after all that time, you know what I've learned?
The estimates were wrong anyway.
Full disclosure: I talk about this stuff a lot. I've got a whole series of YouTube videos on throughput and forecasting that I'll be linking throughout this article. Click if you dare. Or don't -- the article stands on its own. But if you want to go deeper on any of this, the videos are there.
The Estimation Theater Here's what typically happens. The team gets together. Someone describes a feature. Then we go around the room and everyone holds up cards with numbers on them. If the numbers are close, great -- we average them and move on. If they're far apart, we have a "discussion." Which is code for "argument."
The person with the high number explains all the things that could go wrong. The person with the low number explains why it's not that complicated. Eventually, someone compromises, we write down a number, and we move on to the next item.
Two hours later, we've estimated 15 items. We feel productive. We have numbers.
But here's the thing: those numbers are fiction. They're educated guesses dressed up as data. And we treat them like they mean something precise, when really they're just vibes with decimal points.
Why Estimates Fail Estimates fail for a few reasons:
We're bad at estimating. Humans are notoriously terrible at predicting how long complex work will take. We underestimate complexity, forget about dependencies, and assume everything will go smoothly. (It never goes smoothly.)
Story points aren't time. The whole point of story points was to abstract away from time. "It's not hours, it's complexity!" But then we convert velocity to capacity to sprint commitments, and suddenly we're right back to pretending these abstract numbers map to calendar time. They don't.
The useful information gets lost. When someone says "I think this is an 8," what they're really saying is "I'm worried about this." But we don't capture why they're worried. We just write down "8" and move on. The actual useful signal -- the risk, the uncertainty, the concern -- gets compressed into a single meaningless number.
The conversation is backwards. Estimation meetings focus on "how hard is this?" But that's not actually what anyone wants to know. What they want to know is "when will I get my stuff?" or "how much can we deliver by this date?" Story points don't answer those questions directly. They require a bunch of conversion math that introduces even more error.
What If We Just... Stopped? Here's a radical idea: what if instead of estimating how hard things are, we just measured how long they actually take?
This is called throughput. It's embarrassingly simple:
Count how many items you complete each week.
That's it. No complexity points. No Fibonacci debates. Just: how many things did we finish?
Now you have real data. Not guesses. Not estimates. Actual historical performance. If you want to go deeper on throughput, I've got a video: What is Throughput?
Answering the Real Questions Remember those questions I mentioned -- "when will I get my stuff?" and "how much can we deliver by this date?" Throughput answers them directly.
"When will we finish these 20 items?"
If you're averaging about 5 items per week, then 20 items will probably take about 4 weeks. Maybe 3 if things go well. Maybe 5 if they don't.
"What can we deliver in the next 6 weeks?"
At 5 items per week, you're looking at roughly 30 items. So look at your backlog, draw a line after item 30, and that's approximately what's getting done.
No story points required. No conversion math. Just counting.
But Wait -- What About Variability? You might be thinking: "That's too simple. Some weeks we're faster, some weeks we're slower. Some items are bigger than others."
You're right! There is variability. But here's the thing: that variability is already baked into your throughput data.
Look at those weekly numbers again. Week 2 was great (7 items). Week 3 was rough (3 items). That variability -- the good weeks and bad weeks, the big items and small items -- it's all captured in your historical data. You don't need to estimate it. You've already lived it.
I get this objection a lot: "But our items aren't all the same size!" I know. It doesn't matter.
And if you want to get fancy, you can use that variability to give probabilistic forecasts instead of single-point estimates.
Probabilistic Forecasting (With a Music Performance Degree) Probabilistic forecasting sounds like there's gonna be a lot of math. I understand the fear of math. Math hurts. But I want to reassure you that it's not going to be that bad. Heck, I've got a degree that says I should be playing jazz piano in some bar in Brooklyn.
Instead of saying "it'll take 4 weeks," imagine saying this:
"Based on our historical data, there's about a 50% chance we'll finish by March 15th. If you want higher confidence -- say 85% -- we're looking at March 22nd."
This changes the conversation completely.
With traditional estimates, stakeholders either believe you or they don't. You say "two sprints" and they're either nodding along or mentally adding buffer because they've been burned before. There's no middle ground.
But "50% confident by the 15th, 85% confident by the 22nd" gives them something to work with. Need it sooner? They can see exactly what that costs in terms of certainty. Need higher confidence? They can see exactly what that costs in terms of time. Ever had a stakeholder say "just give me a date"? This is how you handle that conversation.
You're not pretending to have precision you don't have. You're being honest about uncertainty -- and giving them the information they need to make actual decisions. More on understanding confidence levels and when will it be done?
The math behind this (it's called Monte Carlo simulation, if you want to Google it) is basically: take your historical throughput data, randomly sample from it a thousand times to simulate a thousand possible futures, and see how often you hit different completion dates. Computers are good at this. You don't have to do it by hand.
The Catch (There's Always a Catch) For throughput to work well, you need to break your work into roughly similar-sized chunks. Not identical -- just roughly similar. If one "item" is a button color change and another "item" is a complete authentication system rewrite, your throughput data is going to be noisy and less useful.
But here's the thing: you should be doing this anyway. Smaller items mean faster feedback, lower risk, and more flexibility. Breaking work down isn't overhead -- it's good practice.
The other thing you need is a few weeks of historical data. You can't forecast from nothing. But you can start measuring today, and in a month you'll have enough data to start making useful predictions.
Try It In Parallel I'm not saying you have to throw away story points tomorrow. But try this: for the next month, keep doing whatever estimation you're currently doing. But also track your weekly throughput. Just count completed items.
At the end of the month, compare. How accurate were your story point estimates? How accurate were your throughput-based forecasts?
My prediction: you'll find that the throughput approach takes less effort and gives you better results. And if I'm wrong, you've lost nothing -- you were doing the estimation work anyway.
The Real Win The best part of switching to throughput isn't even the accuracy. It's the time you get back.
No more two-hour estimation meetings. No more debates about whether something is a 5 or an 8. No more pretending that abstract complexity points mean something precise.
Instead, you spend that time actually building things. And then you count how many things you built. And then you use that count to predict the future.
It's almost disappointingly simple. But simple works.
About the Author
Posted by Benjamin Day on 02/04/2026