How to forecast with confidence intervals

Pick one countable unit and right-size it

Pick the thing you will count finished per week and do not change it mid-quarter.

AI-augmented teams count stories closed. AI-native teams count key user journeys demonstrated, because outcome tickets are too few and too large to sample. Count items, never story points: points get re-baselined every time a team re-points, so rising velocity can mean nothing changed except the scale. Then check the items are interchangeable enough to sample. If single items routinely take more than two weeks, split them at refinement first, because the arithmetic assumes one item is much like another. Write the unit at the top of the forecast.

Pull twelve weeks of throughput history

Export the finished-per-week count for the last twelve weeks.

Eight is the minimum that gives a usable spread. Use the date an item met done, not the date it merged or demoed. Include everything that consumed capacity: stories, bugs linked to the Bug Budget epic, tech debt linked to the Tech Debt epic. Keep the zero weeks and the holiday weeks. They are the tail, and deleting them is the most common way a forecast turns optimistic. If the system changed materially, a team split, a two-week freeze, a switch of delivery mode, shorten the window and accept a wider interval rather than editing the numbers.

Count the remaining scope and inflate it

Count the items left in the roadmap, including the Tech Debt and Bug Budget epics, which are the first things people forget and the last things that stop consuming throughput. Count anything already in progress as remaining, because half-counting it flatters the answer. Then apply your split rate: the items an epic finally shipped divided by the items it carried when it left Ready for Dev, averaged over your last five closed epics. Most teams land between 1.2 and 1.5. If you have never measured it, use 1.3 this quarter and measure it properly for the next one. Forecast against the inflated number.

Simulate ten thousand quarters in a spreadsheet

A spreadsheet is enough.

Put the twelve weekly counts in A1:A12. For the fixed-date question, fill B1 across to J1, one cell per remaining week, with =INDEX($A$1:$A$12, RANDBETWEEN(1,12)), total the row in K1, then fill the block down ten thousand rows. Column K is now ten thousand plausible quarters. For the when-is-it-done question, extend the draws to thirty columns, running-total across the row, and record the first column that reaches your inflated scope. Copy and paste the results as values before reading percentiles, or the sheet resamples every time you touch it. Never average the twelve weeks. The spread is the whole point.

Read p50 and p85, commit at p85

Read the percentiles off the results column with PERCENTILE.INC.

For a date, 0.5 and 0.85 give the week half the simulations finished by and the week 85% of them did. For an item count against a fixed date, the 85% confident number is the 15th percentile of the totals: being 85% sure of delivering at least N items means only 15% of simulated quarters came in below N. Publish one sentence carrying both, for example forty-three items at p50 and thirty-eight at p85. Plan against p50, commit against p85. The gap between them measures how variable your delivery is, and closing it beats pushing the average up.

Convert the shortfall into currency

Rank the remaining epics in the order you will really deliver them, draw a line at the p85 count, and name every epic that falls below it.

Each carries a planned share of its outcome's currency target, so sum those shares and the shortfall stops being a mood and becomes a number. Take it to the outcome owner with three options and no fourth: defer this value to next quarter, cut something above the line to pull it up, or accept that the outcome target moves. Going faster is not on the list, and offering it wastes the meeting and the credibility of the forecast.

Refresh weekly and plot the trend

Re-run it the same morning every week with the new throughput week and a fresh scope count, and keep every version in one sheet: date, sample window, split rate, inflated scope, p50, p85. The useful artefact is not this week's p85, it is the line of p85s across the quarter. Three consecutive weeks drifting later is a signal you can act on in week five, whereas one bad week is noise. Put the current range on the daily dashboard next to the quarter end date, so divergence surfaces before stand-up rather than at a steering meeting in week eleven.

Check your calibration at roadmap close

At roadmap close, write down three comparisons: the p85 count you published against what finished, the forecast completion week against the real one, and the split rate you assumed against the one you got. Four quarters of that gives you a realisation rate, and if your organisation reliably realises 70% of what it plans, 70% is the number next quarter's planning uses rather than optimism. If actuals fall below p85 more often than roughly one quarter in six, the sample window is flattering you: too short, too recent, or missing the bad weeks.