When will it be done? Estimates, probabilistic forecasts and a delivery date you can defend

The defensible answer to "when will it be done" is not one date but two: "October 12 at 50 percent, October 26 at 85 percent." Dates slip for three reasons that have nothing to do with how fast a team writes code. A single-number estimate quietly turns into a commitment somewhere between the meeting and the roadmap. Nobody records how long finished work actually took. And the items added to the list after the forecast was given never make it back into the forecast. Fix those three and your estimates do not become magically accurate. You need fewer of them, because you can forecast from your own data instead.

Estimate, target and commitment are three different things

Steve McConnell's distinction is where this conversation has to start. An estimate is a prediction of how long something will take, and by its nature it is a range or a probability distribution rather than a number. A target is a desirable business outcome: "it should be ready for the November trade show." A commitment is a promise to deliver defined functionality at a defined quality by a specific date. A commitment can match the estimate, or it can be more aggressive, or more conservative.

The accident we see most often is all three colliding in one meeting. An executive asks for "an estimate" while actually asking for a commitment, or for a plan that hits a target. The team says "three to six weeks" in good faith and the other side writes down "three weeks." Nobody lied, and yet there is now a promise that nobody agreed to. Separating the words costs nothing: write down which sentence is the estimate and which one, if any, is the commitment.

The real problem is not error, it is overconfidence

Magne Jørgensen's 2004 review in the Journal of Systems and Software notes that published surveys typically report average effort overruns of about 30 percent. That number is good news, in a way, because 30 percent is a deviation you can plan around. The second finding in the same review is the uncomfortable one. When a software professional says with 90 percent confidence that the true effort falls between a stated minimum and maximum, the true effort actually lands inside that interval only 60 to 70 percent of the time. The range you gave is narrower than it felt when you gave it.

The tail behaves worse than the average. Bent Flyvbjerg and Alexander Budzier studied 1,471 IT projects for a 2011 Harvard Business Review article. Average cost overrun came out at 27 percent, consistent with the figure above. But one project in six behaved like a black swan, with an average cost overrun of 200 percent and a schedule overrun of nearly 70 percent. The management lesson there is about portfolio, not estimation technique: you can plan against the average, but you cannot plan against the tail. Do not tie the entire budget and a single immovable date to one risky programme. We covered what that uncertainty does on the contractual side in the piece on fixed price versus time and materials.

Do not reveal the budget before you get the number

Mentioning a target date or a budget before asking for an estimate affects the answer you get. Laboratory work by Jørgensen and Stein Grimstad shows numerical anchors having strong effects on effort estimates. Their field experiment, published in IEEE Transactions on Software Engineering in 2011, paints a more careful picture: 46 outsourcing companies were paid to estimate the same five projects, each randomly assigned either the original requirements specification or a manipulated version (shortened text, information about the client's low budget expectations, a restricted development window). The effect sizes in the field were far smaller than in the lab, and many did not reach statistical significance.

So anchoring is not an iron law that fires every time. It is, however, free to guard against, which makes it silly not to. Ask for the estimate, get it, then discuss the budget and the target date. Apply the same care to how the work is framed in words. Describing a piece of work as "a small addition" produces different numbers than describing the same work as "a new module."

You cannot forecast what you do not measure, and measuring means two dates

The May 2025 version of the Kanban Guide defines four flow metrics, all of which come from the same two fields on a work item:

• WIP: the number of work items started but not finished.
• Throughput: the number of work items finished per unit of time, counted as items rather than points.
• Work item age: the elapsed time between when an item started and today.
• Cycle time: the elapsed time between when an item started and when it finished.

The guide is deliberate about leaving the meaning of "started" and "finished" to the team's own definition of workflow. That detail sounds procedural and turns out to decide the quality of everything downstream. For one team "started" is when the card moves out of the backlog, for another it is the first commit, and weeks can sit between those two points. The only requirement is that everyone draws the line in the same place. Teams that never capture these two dates are forced to invent a fresh estimate for every question, with the same optimism each time.

Dividing by the average is a coin flip, not a plan

Forty items left, five finished per week on average, so eight weeks. The arithmetic is right and the forecast is useless. A date produced from an average is roughly a 50 percent outcome at best, meaning it has about the same odds as a coin flip, and it throws away everything the distribution knows about bad weeks.

A Monte Carlo approach uses the same data far more honestly. Take the weekly count of finished items from the last 8 to 12 weeks. Draw from those numbers at random, with replacement, and count how many weeks it takes to clear 40 items. Repeat that tens of thousands of times. Now you have a distribution rather than a number, and you can read the 50th, 85th and 95th percentile dates off it. It takes about half an hour to build in a spreadsheet, and there are ready-made tools if you would rather not.

There is one rule for choosing the input data: use the history you believe will resemble the future you are forecasting. A team formed two months ago does not have a three-month history. If half the team changed or the type of work shifted, cut the old data, and be wary of anything older than six months.

Teach the organisation to speak in percentiles

What the Kanban Guide calls a service level expectation is exactly this: a period of time plus an associated probability. The example in the guide reads "85 percent of work items will be finished in eight days or less." It also says to start with a best guess if you do not yet have enough history, and to replace the guess with real numbers as data accumulates.

Giving the business two dates looks evasive on first contact and works out as the opposite. The conversation stops being "did the date hold" and becomes "which probability are we operating at." Choosing 85 percent for a delivery tied to a trade show and 50 percent for an internal improvement is now a deliberate business decision. The team gets something back too: the bottom end of the range stops being recorded as a promise.

The thing wrecking your date is usually WIP

Little's Law ties three of the metrics together: average cycle time equals average WIP divided by average throughput. With 24 items in progress and 8 items finished per week, average cycle time is 3 weeks. If the same team, working at exactly the same rate, cuts items in progress to 12, average cycle time drops to about a week and a half. Nobody got faster. The queue got shorter.

The law needs a stable system to hold: over the long run, work entering has to match work leaving, and everything started has to eventually finish. When that condition fails, the broken thing is not the formula. In a large share of late projects the team is not slow, it started eight things at once.

Drop the percent-complete question and look at age

"What percentage is done" carries no information. Ninety percent can last for weeks, because the remaining ten percent is usually integration, review and rework. Work item age carries information and cannot be talked up or down, because it comes from the calendar rather than from anyone's judgement.

Using it is simple. List every item currently in progress with the number of days it has been open, then compare against your cycle time percentiles. If 85 percent of your items finish within eight days, an item that has been open for twelve days is already late right now. That gives you the delay while there is still time to act, rather than on the delivery date. These signals arrive late in teams without continuous integration and automated tests, which is why a working deployment pipeline is a precondition for forecasting rather than a separate topic.

What really breaks forecasts: everything added afterwards

Every forecast assumes scope holds still. It does not. New requests arrive, an item splits in two the moment someone opens it, an overlooked dependency spawns three more. The team keeps its promises, the date moves anyway, and nobody names the cause.

Measure it instead: how many new items enter the list each week, and what share of started items get split? A team that knows those two rates feeds the Monte Carlo forecast an item count inflated by a multiplier, and moves the discussion onto the right axis. The question stops being "are we slow" and becomes "how much did scope grow in six weeks." Once that is on the table the decision goes back to the business: the date or the scope. This is exactly why fixing the date and letting scope flex works so well when you are deciding what goes into an MVP.

The outside view: your own history is the best reference class

Reference class forecasting rests on the decision research that earned Daniel Kahneman the 2002 Nobel prize in economics. The idea is plain: instead of looking inside the planned work (the inside view), look at how similar past work actually turned out (the outside view). After Flyvbjerg and colleagues documented how badly demand forecasts missed on public projects, the American Planning Association formally endorsed the method in 2005 and advised planners never to rely on conventional forecasting techniques alone.

The software version is unglamorous and effective. "This resembles the accounting integration we did last year, and that took 11 weeks" is a better starting point than "I think about 4 weeks." It has one prerequisite: somebody has to be keeping the actual durations of finished work. In most teams that data is already sitting in the issue tracker and nobody has ever queried it.

Where expert estimation is still the best tool available

Being honest about the limits: history is not always there. A team formed last month, a type of work nobody has done before, a legacy system nobody has touched in years. In those cases you have no reference class, and expert judgement remains the best instrument you have. Jørgensen's review says as much, finding no substantial evidence in favour of replacing expert estimation with formal models.

For a team doing similar work repeatedly, the balance flips. There, historical data outperforms expert judgement, costs nobody a lunch break and keeps the discussion off individual performance. When you are modernising a legacy system incrementally, the real duration of the first few slices becomes the most valuable data you have for everything that follows.

What fits into this week

Three things. First, pull the weekly count of finished items for the last 12 weeks out of your issue tracker, counted as items rather than points. Second, sort everything currently in progress by age and discuss the three oldest in today's standup. Third, give two dates instead of one for the next delivery, and write down the scope you assumed alongside them.

With those three in hand, the next answer to "when will it be done" rests on measurement rather than instinct. If you want help pulling your own numbers, or fitting probabilistic forecasts into how your organisation actually makes decisions, we can look at the data you already have and work out where to start.