How to forecast delivery with confidence intervals

Eight weeks is the working minimum and twelve is comfortable. What matters more than the length is whether the window describes the system you are in now. If the team doubled, the delivery mode changed, or the quarter opened with a two-week freeze, use the weeks since that change and accept a wider interval rather than padding the sample with data from a team that no longer exists. A wide honest range beats a narrow invented one.

Borrow a reference class for the first six weeks by taking the weekly throughput of a comparable team in the same organisation, labelling the forecast clearly as borrowed history, and publishing a deliberately wide range. Replace one borrowed week with a real one every week until the sample is entirely yours. What you must not do is fall back on a single date because you have no data, since that is the situation in which invented dates are least defensible. Tenhaw borrows history the same way at the start of a build engagement, before the new team has weeks of its own to sample.

Give them p85 as the committed number and keep p50 as the internal plan, then say the remaining 15% out loud so nobody is surprised later. The range is not there for comfort, it is there to produce the currency number. James Rooney runs every Tenhaw engagement, so the partner is the one holding that conversation with the outcome owner. Once the value at risk is on the table, the conversation stops being about whether the date is right and becomes a decision about which value gets deferred, which is the only version anyone can act on.

No. Ten thousand rows and two formulas in a spreadsheet produce the same answer as any Monte Carlo tool, and doing it by hand for a quarter teaches you where the forecast is fragile. Tools earn their place later, when you want the weekly refresh and the trend of p85 maintained without someone remembering. Buying one first does not help, because the arguments are always about the inputs, the unit, the window and the split rate, not about the maths.

A p50 is the point half your simulated quarters finish by, and a p85 is the point 85% of them do. Resample your own weekly throughput history into ten thousand plausible quarters and read both percentiles off the same results. This arithmetic is published in full by Tenhaw and free to adopt without hiring anyone. The team plans against the p50, the business commits to the p85, and the gap between them measures how variable your delivery is, so closing that gap beats pushing the average up. Publish both in one sentence, for example forty-three items at p50 and thirty-eight at p85, so nobody mistakes the coin-flip number for the commitment.

Counted items, always. Story points get re-baselined every time a team re-points, so a velocity line measures the scale as much as the work, and a rising line can mean nothing moved. Counted items cannot be quietly inflated. Pick one unit and do not change it mid-quarter, whether that is stories closed for an AI-augmented team or key user journeys demonstrated for an AI-native one, because outcome tickets are too few and too large to sample well. Write the unit at the top of the forecast, check the items are interchangeable enough to sample, and split anything that routinely takes more than two weeks at refinement first.

Inflate the remaining scope by your split rate before you forecast against it. The split rate is the number of 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. Unmeasured scope growth is why teams forecast accurately against the backlog they counted and miss anyway, since the epics grew by a third between Ready for Dev and release. Count anything already in progress as remaining too, because half-counting it flatters the answer.

Put your last twelve weekly finished-item counts in A1:A12, fill one cell per remaining week with =INDEX($A$1:$A$12, RANDBETWEEN(1,12)), total the row, and fill the block down ten thousand rows. The totals column is now ten thousand plausible quarters. Read it with PERCENTILE.INC, where 0.5 gives the p50 item count and 0.15 gives the 85% confident one, because being 85% sure of at least N items means only 15% of simulations fall below N. For a completion date instead, extend the draws to thirty columns, running-total across the row, and record the first column that reaches your inflated scope. Paste the results as values before reading percentiles, or the sheet resamples every time you touch it.

No. Keep the zero weeks, the incident weeks and the week between Christmas and New Year, because they are the tail of your distribution and the tail is where the misses live. Deleting the weeks that look unrepresentative removes exactly the variability the interval is meant to price, leaving a confident forecast of a quarter you have never actually had. It is also the most common way a forecast quietly turns optimistic. The one legitimate reason to drop history is a material change to the system, a team split, a two-week freeze or a switch of delivery mode. In that case, shorten the window to the weeks since the change and accept a wider interval rather than editing the numbers.

Convert the shortfall into currency and take it to the outcome owner as a decision. Rank the remaining epics in the order you will really deliver them, draw a line at the p85 count, and name every epic below it with its planned share of its outcome's currency target. Summed, those shares turn the miss from a warning into a number. Tenhaw reports any month that delivers no measurable value as a failed month. Then offer three options and no fourth: defer that 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.

Yes, and the reason is the trend rather than this week's number. Re-run it the same morning every week with the new throughput week and a fresh scope count, and keep every version as a row in one sheet: date, sample window, split rate, inflated scope, p50 and p85. The useful artefact is the line of p85s across the quarter, because one bad week is noise while three consecutive weeks drifting later is a signal you can act on in week five. 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.

Mark them at roadmap close and 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. Do that for four quarters and you know whether to believe the next forecast, which is the only honest reason anyone should. There is a faster diagnostic in the meantime. 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. Keep the published numbers somewhere you can find them later, or there is nothing to mark.

It does, with three adjustments. An AI-native team counts key user journeys demonstrated rather than stories closed, because outcome tickets are too few and too large to sample well, and pulls sixteen weeks of history rather than twelve. Expect a wider p50 to p85 gap and publish it rather than smoothing it. A change of model, harness or verification standard changes the system as much as a team split does, so throughput history goes stale faster and each of those is a reason to shorten the window. And measure the split rate rather than assuming it, because outcome tickets grow more between approval and done than stories do. Tenhaw publishes its own engineering standard as 72 rules on GitHub, enforced by an agent rather than remembered.

About two hours the first time, then roughly half an hour a week to keep it current. Most of those two hours goes on inputs rather than maths: exporting twelve weeks of finished-per-week counts, deciding the one unit you will count and not change mid-quarter, counting the remaining scope including the Tech Debt and Bug Budget epics and everything in progress, and working out your split rate from the last five closed epics. The simulation itself is two formulas and a fill-down in a spreadsheet. Tenhaw pair-programs this with a client engineer so the sheet stays theirs. You leave that first sitting with a p50 and a p85 you can publish, and every week after it is an update rather than a project.

Because an average only answers what happens if every remaining week is an average week, which is not a question anybody asked. Take a team whose last twelve weekly counts were 5, 3, 7, 4, 6, 2, 5, 8, 4, 5, 3 and 6. That averages 4.8 a week, so nine weeks looks like 43 items, which is exactly the p50 the simulation gives. Resampling the same history puts p85 at 38, and those five items are the risk the average deleted. Worse, it deletes the tail while it is at it, the zero weeks and the incident weeks, and the tail is where the misses actually live.

The unit you counted, the sample window and the split rate you used, written next to the numbers so anyone can reproduce them, and no single date anywhere in the document. Add the date it was last refreshed, because a forecast older than a week is history rather than a forecast. If the p85 falls short of the quarter, name every epic below the line with its planned share of its outcome's currency target, so the value at risk is a number rather than a warning, then record what the outcome owner decided. Published that way, the inputs are on the table and the meeting argues about the decision instead of the maths.

Yes, on both sides of the arithmetic. Throughput history should include everything that consumed capacity: stories, bugs linked to the Bug Budget epic, and tech debt linked to the Tech Debt epic. Use the date an item met done, not the date it merged or demoed. The remaining scope count has to include those same epics, which are the first things people forget and the last things that stop consuming throughput. Leave them out of both and you have forecast a team that only ever does feature work, which is not the team you have.