Stop Estimating. Start Forecasting.

A team sits in a room and argues about whether a ticket is a 3 or a 5. Someone invokes the Fibonacci sequence. Someone else points out that the last 5 took longer than the last 8. They settle on a 5 because it's nearly lunch. This number will be summed with other numbers, divided by a sprint count, and presented to leadership as a forecast.

Everyone in the room knows the number is fiction. They produce it anyway, every two weeks, because estimation is what teams do.

Here's the thing the ritual obscures: your team is already generating real data about how fast it ships. That data predicts the future better than any estimate. You don't need to guess harder. You need to count.

Why estimates are structurally bad

The problem with estimation isn't that engineers are bad at it. It's that the task is impossible in principle, for reasons no amount of skill or process can fix.

You're estimating the unknown. The reason a task takes longer than expected is almost always something you didn't know when you estimated — a hidden dependency, an API that doesn't behave as documented, a test environment that's broken, a requirement that was ambiguous. By definition, you cannot estimate the cost of things you don't yet know exist. The estimate is a guess about the known part of the work, and the known part is rarely what blows the timeline.

Estimates ignore the system. A task's calendar duration is dominated by waiting, not working. Waiting for review, waiting for QA, waiting for a deploy window, waiting for an answer from another team, sitting in a "blocked" column. An estimate of "two days of effort" says nothing about the five days that ticket will spend idle in the pipeline. The estimate measures effort; the stakeholder hears duration; those are different quantities.

Story points launder the guess. Points were introduced to avoid the false precision of time estimates — to estimate relative complexity instead. In practice, every team silently converts points back to time ("a point is about a day"), and leadership treats velocity as a delivery commitment. You've added an abstraction layer and a translation step, and arrived right back at a time estimate, now with extra ceremony.

The estimate becomes a target. Once a number is spoken, it stops being a prediction and becomes a deadline. Engineers pad to protect themselves, then expand work to fill the padding. Or they cut corners to hit the number and the corners become next quarter's incidents. The act of estimating changes the behavior it was trying to measure.

Add it up and the estimation ritual costs hours of senior engineering time per sprint to produce a number everyone knows is wrong, that distorts behavior, and that predicts the future poorly.

What actually predicts delivery

There's a better input, and your team is already producing it: cycle time — the actual elapsed time, start to finish, for the work items you've already completed.

Pull the last two or three months of completed tickets and, for each, measure the calendar time from "started" to "shipped." Don't estimate anything. Just record what happened. You now have a distribution — and that distribution is the most honest forecasting tool you will ever have, because it already includes everything estimates miss: the unknowns, the waiting, the review queues, the bad days. It happened, so it's all in the number.

That distribution will be wide. You might find half your tickets ship within 4 days, 85% within 11 days, and a long tail running past 25. That spread isn't noise to be averaged away — it is the signal. It's the honest shape of how your team delivers, and pretending it's a single number is the original sin of estimation.

Forecasting with the distribution

Once you have the cycle-time distribution, forecasting becomes counting instead of guessing.

Forecast single items as ranges with probability. Instead of "this ticket is a 5," say: "based on our last 80 tickets, there's an 85% chance this ships within 11 days." That's not a hedge — it's an honestly scoped commitment. Stakeholders can plan around "85% by the 11th" in a way they never could around a point estimate that's silently wrong half the time.

Forecast a backlog by throughput. To predict when 30 tickets will be done, you don't estimate 30 tickets. You measure throughput — items completed per week — over recent history, and divide. If the team has steadily finished 6–9 items per week, 30 items is roughly 4–6 weeks. The forecast is a range derived from measured reality, and it took two minutes instead of a planning meeting.

Run a Monte Carlo simulation for the real questions. When the question is "what can we deliver by the end of the quarter," sample randomly from your historical throughput thousands of times and look at the spread of outcomes. The output is a probability curve — "70% chance of finishing 40+ items, 95% chance of 28+." This sounds heavy; it's a short script or an off-the-shelf tool. It consumes data you already have and produces a forecast no estimation meeting can match.

The throughline: stop asking engineers to predict the future from intuition. Use the recorded past, which already contains every factor a guess leaves out.

What you give up, and what you keep

Dropping estimation does cost you two things, and both have better replacements.

The first is the conversation. Estimation meetings do surface real disagreements — "wait, this needs a schema migration?" — and that's genuinely valuable. Keep the conversation, drop the number. A short scoping discussion that ends in shared understanding and a split of anything too big is the useful 20% of planning. The number was never the point.

The second is the forcing function to break down work. Big estimates pressure teams to split tickets, which is good — small items flow faster and more predictably. Replace that pressure with a direct rule: any item that can't plausibly finish within your 85th-percentile cycle time gets split before it starts. Same outcome, no points.

Notice the precondition for all of this: you need to know when work started and when it shipped. Most issue trackers record this already, or can with one workflow tweak. That's the entire setup cost. No new ceremony, no new tool to roll out — just stop discarding the timestamps you're already collecting.

Estimation asks your most expensive people to guess, on a schedule, at something unknowable, and then treats the guess as a commitment. Forecasting asks a simpler question — what has actually happened lately, and how much of it — and answers with a probability. One of those is a ritual. The other is measurement. Your team already has the data. Stop guessing and start counting.