There are forty items left before the release and over the last twelve weeks the team has finished between four and nine a week. The sponsor wants a date. What do you tell them?

The average is the one number you should not use

Dividing forty by an average weekly throughput gives you a single date, and that date is roughly a coin flip. It carries no information about how wrong it might be, which is the only thing the sponsor genuinely needs, and it will be reported upwards as a commitment because a single number with no qualifier reads as one.

The spread is the data. A team whose weekly counts sit between four and nine has told you something specific about how variable its delivery is, and that variability propagates into the finish date. Throwing it away by averaging is the mistake, and it is the mistake almost everybody makes, including people who can recite flow metrics fluently.

The arithmetic, with every input on the table

Take a concrete twelve weeks of completed items, in order: 4, 9, 6, 5, 7, 4, 8, 6, 5, 9, 6, 5. That sums to seventy-four items over twelve weeks, so the mean is about 6.2 items a week.

The naive forecast is forty divided by 6.2, which is about 6.5 weeks. Now bound it with the observed extremes rather than inventing bounds. If the team sustained its worst observed rate of four a week, forty items take ten weeks. If it sustained its best of nine a week, they take between four and five. So the honest statement before any further refinement is somewhere between four and a half and ten weeks, with the middle of the distribution near six or seven.

The better method uses the same twelve numbers without assuming any distribution: draw a week at random from those twelve, then another, accumulating completed items until you pass forty, and record how many weeks it took. Repeat that a few thousand times and you have a set of possible durations you can read percentiles off. That is a Monte Carlo forecast, and its whole advantage is that it needs no assumption you have to defend — the input is literally the team's own history, and a sponsor can be shown the twelve numbers it was built from.

What you then quote is a percentile, not a date. The eighty-fifth percentile of that distribution is a date you will beat about five times in six, which is usually the right thing to put in a plan. The median is a date you will miss about half the time, which is the right thing for internal planning and the wrong thing for a customer commitment.

Scope growth is the term everyone drops

Here is the calculation that separates a real forecast from a tidy one. The forty remaining items are not a fixed quantity. Over those same twelve weeks the backlog will also have grown, because acceptance criteria expand, defects are found, and things nobody thought of become necessary.

So measure it. Suppose that across those twelve weeks, while seventy-four items were completed, eighteen new items were added to the remaining scope. That is 1.5 items a week of growth, and the net rate at which the backlog is shrinking is 6.2 minus 1.5, which is about 4.7 items a week. Forty items at 4.7 a week is roughly 8.6 weeks, not 6.5. The forecast moved by two weeks purely because the term was included, and that gap is where most missed dates come from.

Two things follow. First, if you have never measured the arrival rate, say so rather than guessing at one; the honest version is that your forecast has an unbounded term in it, and finding out costs one afternoon in the tracker. Second, the arrival rate is the most controllable input in the whole calculation. Telling a sponsor that the date moves out two weeks because of scope added since the plan is a much more useful conversation than telling them the team is slow.

Say which promise you are making

The sponsor hears a date and treats it as a commitment unless you make the distinction explicit. Do that in words, at the moment you give the number.

What not to say	What to say
"About six weeks."	"At the rate we have actually run for three months, forty items takes eight to nine weeks. I would plan on nine."
"We will try to hit the eighteenth."	"The eighteenth is a date I would beat about five times in six. The eleventh is closer to even money."
"It depends on too many things to say."	"Here are the twelve weeks it is built from. Argue with any of them and I will redo it in an hour."
"We can commit to it if we work weekends."	"I can commit to the eighteenth for thirty-two of the forty items. Which eight would you drop?"

That last row is the one that changes the conversation, because it converts a request for certainty into a choice the sponsor can make. Fixing a date and fixing scope simultaneously is the thing you cannot do, and offering the trade is more useful than refusing the question.

When counting items is the wrong unit at all

This method assumes the forty items are roughly comparable in size, which is what makes counting them legitimate. Check that assumption rather than inheriting it. If three of the forty have never been looked at and might each be a month, then the count is a fiction and no percentile rescues it; the right answer is a timeboxed investigation into those three and a forecast for the other thirty-seven, reported separately.

The other case where item counting misleads is a release that is not done until several items land together. Throughput tells you when forty items are complete, not when a coherent thing is releasable, and if the last three items must all be finished before anything ships then the variability of those three dominates. A forecast built on the average behaviour of the whole set will be optimistic about a release gated on its slowest component.

Name what would invalidate it

Finish by saying what makes the forecast wrong, because the sponsor's real question is how much they can rely on it and a stated failure condition answers that better than a confidence level does. The conditions worth naming are a change in the team, since the twelve weeks describe this team and not a different one; a change in what counts as done, which changes the unit; a period of the sample being unrepresentative, such as a fortnight lost to an incident, which you should either exclude and say so or keep and say so; and the arrival rate rising, which is the one most likely to actually happen.

Then re-run it every week and report the movement. A forecast that is refreshed weekly and drifts by half a week is a system under control; a forecast quoted once in March and defended in June is how a project gets to be three months late while every report said green.