Forecast without estimating anything
Resample your own throughput history. How long for these items, or how many by that date — with the confidence attached, and no story points required.
Forecasting without estimating anything
Resample your own throughput history. No story points, no task breakdown — just how many things you have finished per week.
How long for those items
How many in that time
How the forecast works
Each run draws periods at random from your own history, with replacement, and counts until the target is reached. Ten thousand runs give a distribution.
Resampling rather than fitting a curve is deliberate. Your history already contains the holiday weeks, the incident, the sprint that went sideways. A smooth distribution fitted to that data removes exactly those events, and they are the reason forecasts slip.
The two questions read from opposite tails. For "how long", the cautious answer is the HIGH percentile — 85% of runs finished by then. For "how many", the cautious answer is the LOW one — you delivered at least that much in 85% of runs. Reading the wrong tail turns a safe forecast into an optimistic one, and it is an easy mistake to make.
The seed is exposed so a forecast can be reproduced.
Why this beats estimating
A forecast built from throughput needs no estimates at all. It does not care whether items are the same size, because the history already reflects however big they were — a period where everything was large shows up as a low count, which is exactly the information you want.
This is liberating for teams who have abandoned story points and awkward for the argument that estimation is necessary for predictability. Counting what you finished is usually more predictive than estimating what you are about to start.
The assumption that will break it
It assumes the future resembles the recent past. A reorganisation, a shift to unfamiliar work, half the team leaving, or a change in what counts as an item all break that, and nothing in the arithmetic will warn you.
The practical guard is to use recent history rather than all of it, and to re-forecast often. Twelve weeks of current data beats two years spanning three different teams.
Item size matters less than you would think
The common objection is that items are not the same size, so counting them is meaningless. In practice, for a team working on a reasonably consistent flow of work, the variation in size averages out across a period — and the forecast is built from periods, not items.
Where it genuinely breaks is when one item is an order of magnitude larger than the rest. Splitting that item is a good idea for several reasons, and this is one of them.