Delivery forecasting

This is the exact file agents read, including the credit header and licence notice. Save it as delivery-forecasting/SKILL.md.

---
name: delivery-forecasting
description: Forecast when roadmap work will be delivered as a date range with a probability, from how fast the team actually finishes work, instead of a single guessed date. Covers choosing the unit (completed item count, not story points), gathering at least six sprints or eight to twelve weeks of throughput, sizing scope as a low-to-high range, running a Monte Carlo simulation of about ten thousand trials, reading the 50th, 85th and 95th percentiles as confidence levels (internal, stakeholder and high-stakes), a Little's Law sanity check, reference-class forecasting when data is thin or the team is new, and the stakeholder conversation when a date has already been promised. Use it when someone says when will this be done, forecast the delivery date, how many can we finish by the deadline, give me a confidence range, our estimates keep slipping, or turn this roadmap into dates. Do NOT use it to rank what to build (see prioritisation-frameworks), to decide the order of work (see roadmap-sequencing), or to choose the roadmap format (see product-roadmapping).
license: CC BY 4.0. Free to use and adapt with credit to Afeez Adebayo, linking afeezadebayo.com, his LinkedIn (https://www.linkedin.com/in/afeez-adebayo/) and the skill's download page.
---

# Delivery forecasting

A single delivery date is a guess dressed as a promise. The team that says "it will be done on the 14th" is almost always wrong, usually late, because a point estimate hides the range of things that can happen and the optimism that creeps into every plan. This skill makes an AI agent forecast delivery the way a meteorologist forecasts rain: as a date range with a probability attached, built from how fast the team has actually been finishing work rather than from how fast someone hopes it will go. It produces the dates; it does not rank the work, order it, or format the roadmap. Ranking is prioritisation-frameworks, order is roadmap-sequencing, and roadmap format is product-roadmapping. A forecast is the honest answer to "when", and this skill keeps it honest.

## When to use this skill, and when not to

Use it when someone needs a delivery date, a completion range, or a confidence level for a backlog, an epic, a release or a roadmap item. Use it when someone says when will this be done, forecast the delivery date, how many items can we finish by the deadline, give me a date I can commit to, our estimates keep slipping, or turn this roadmap into dates.

Do not use it to decide which work is worth doing or to rank a backlog; that is prioritisation-frameworks. Do not use it to decide the order of delivery or to resolve dependencies; that is roadmap-sequencing, which should run first so the forecast models the real order. Do not use it to choose how the roadmap is drawn or communicated; that is product-roadmapping. Do not use it to produce a single confident date with no probability attached, because that is the exact failure this skill exists to prevent.

## What the agent must have before starting

Ask for whatever is missing, and never invent a throughput figure or a date:

1. Throughput history: how many work items the team completed in each of the recent weeks or sprints. At least six sprints, or eight to twelve weeks, is the working minimum; fewer data points widen the range and lower the reliability. If there is no history at all, go to the reference-class path in Step 6 rather than guessing a velocity.
2. The scope, counted as a number of items, not as story points. If scope is uncertain, a low and a high item count (the smallest and largest plausible number of items) so the forecast can model both.
3. A start date, because a "when will it be done" forecast is a number of weeks from a start, and the calendar date depends on when work begins.
4. Whether the team and its conditions are stable. A forecast from past data is only valid if the future resembles the past; a team that has just changed size, changed the type of work, or changed its process needs its forecast treated with caution until new data accumulates.
5. What decision the forecast will drive and who will read it, because that sets which confidence level to report and whether a date is about to become a commitment.

If someone hands you story-point velocity and asks for a date, convert the request to item count if you can, because story-point estimates correlate poorly with actual delivery time; if you cannot, forecast from velocity but say plainly that item-count throughput is the more stable input.

## The workflow

### Step 1: Choose the unit and keep item sizes comparable

Forecast from the count of completed items per period, not from story points. Item count is more stable than points, and point estimates show almost no correlation with how long work actually takes. Keep the items roughly comparable in size: before pulling an item into scope, check that it can plausibly finish within a target window (for example twelve days) rather than enforcing identical sizes. Split anything much larger, because one giant item wrecks the throughput distribution. If the backlog mixes wildly different sizes, the forecast still works but the range widens, so note that.

### Step 2: Gather throughput history as a rolling window

Collect completed-item counts for each recent week or sprint. Use at least six sprints, or the last eight, twelve or twenty-six complete weeks, as a rolling window that moves forward as new data lands. More history narrows the range only while conditions stay similar; old data from a different team or a different kind of work is worse than less recent data. Record whether throughput is steady or spiky, because steady throughput produces a narrow, trustworthy forecast and spiky throughput produces a wide one that is still honest.

### Step 3: Size the scope as a range, not a single number

Express the work as a low and a high item count. The low is what you will almost certainly have to do; the high includes the items that might appear or split out as the work is understood. Scope growth, not team speed, is the most common reason a forecast misses, so modelling a scope range is what stops a forecast being quietly invalidated the first time a story splits into three.

### Step 4: Run a Monte Carlo simulation

Simulate the future many times by sampling the throughput history at random, with replacement. For "when will N items be done", keep drawing weekly throughput samples and adding them until the simulated total reaches the scope, and record how many weeks that trial took; repeat for about ten thousand trials. For "how many items by date D", draw the number of weeks between now and D and sum the sampled throughput, again over about ten thousand trials. Aggregate the trials into a histogram of completion dates or item counts. Ten thousand trials is a sensible default; the method works with far fewer but the percentiles get noisier. Even a handful of data points gives a usable start: with five samples there is about a 94 per cent chance the true median sits between the smallest and largest you have seen, so begin forecasting early and let the range tighten as data grows.

### Step 5: Read the percentiles as confidence levels

Each percentile is a confidence level: the share of trials that finished by that point or earlier. Read them, do not average them, because the average hides the risk.

- 50th percentile (coin flip): internal planning and scenario talk only. Never commit to it; half the time the work runs longer.
- 85th percentile: the default for a roadmap or a stakeholder date. Start here unless there is a reason to move.
- 95th percentile: high-stakes only, a contractual or regulatory date where missing it costs far more than the buffer.

Moving from the 50th to the 95th percentile more than triples the range of outcomes, so the gap between "possible" and "safe" is large and worth showing. As a sanity check, Little's Law says average work in progress equals average throughput multiplied by average cycle time; if the forecast implies a throughput the team has never sustained at its current work-in-progress, the forecast is wrong, not optimistic.

### Step 6: When data is thin or the team is new, forecast from a reference class

With too little history, dissimilar past work, or a brand-new team, do not fabricate a throughput; take the outside view. Reference-class forecasting estimates from the outcomes of similar past projects rather than from the specifics of this one, which is the documented cure for the planning fallacy, the reliable human tendency to underestimate time and cost. The evidence is stark: across 1,471 IT projects, the average cost overrun was 27 per cent, but one in six was a "black swan" with a 200 per cent cost overrun and almost a 70 per cent schedule overrun, and the overrun distribution has a fat tail. Build a reference class of comparable past efforts (by size, complexity and type), use their actual durations as the forecast, and break any large project into smaller pieces, because smaller scopes have thinner tails. Label a reference-class forecast as such, and replace it with the team's own throughput as soon as enough accumulates.

### Step 7: Communicate as a range, and re-forecast

Report the forecast as a range with probabilities, never as a single date, and state the scope, the history window and both the 50th and 85th results, plus what happens if scope grows or throughput drops. Re-run the forecast every sprint as scope and throughput evolve; a forecast is a snapshot, not a one-time promise, and a stale one is worse than none. Expect resistance: stakeholders often want certainty, not a probability, and the hardest case is when a date was promised before the forecast existed, so the forecast is heard as an attack on a commitment already made. Handle it by separating the forecast from the commitment, showing what would have to be true (more throughput, less scope) for an earlier date to be safe, and leaving the decision to commit with a person. Committing a date to a customer, a board or a market is an irreversible promise, so this skill produces the forecast and a recommended confidence level; a human makes the commitment.

## Worked example

Input: a backlog of about 40 items (low 40, high 55 to allow for splits), one team, start date next Monday, and the last ten weeks of completed-item counts: 6, 4, 7, 5, 3, 8, 6, 5, 4, 7.

Step 1 confirms the work is counted as items and the sizes are broadly comparable. Step 2 takes all ten weeks as the window and notes throughput is moderately steady (three to eight per week). Step 3 sets the scope range at 40 to 55. Step 4 runs ten thousand trials: each trial keeps drawing a weekly number from the ten observed values until the running total reaches the scope, and records the week count. Step 5 reads the histogram. For 40 items, the 50th percentile lands around week 7, the 85th around week 9, and the 95th around week 10; for the 55-item high scope, each shifts out by two to three weeks. The agent reports: "At the current pace, 40 items is 85 per cent likely to finish within 9 weeks (by [date]); if scope grows to 55, that moves to about 12 weeks. The 50 per cent figure is 7 weeks, which is for internal planning only, not a date to promise." It then flags that the single biggest risk to the date is scope growth, not speed, and offers to re-run the forecast after the first sprint.

## Templates you can use verbatim

Forecast statement: "[Scope] items, starting [date], from [N] weeks of throughput: 85 per cent likely to finish by [date] ([W] weeks); 50 per cent by [earlier date] (internal only). If scope grows to [high], the 85 per cent date moves to [later date]. Re-forecast after the next sprint."

What-if line: "If throughput drops 20 per cent, the 85 per cent date moves to [date]. If we cut scope to [N] items, it moves to [date]."

Reference-class statement (thin data): "We have too little history to forecast from this team, so this is an outside-view estimate from [K] comparable past efforts, which took [range] to deliver similar scope. Treat it as a starting range and replace it with this team's own throughput after [N] sprints."

Stakeholder script (date already promised): "The forecast does not change what we want; it tells us the odds. At today's pace, [promised date] is around a [P] per cent chance. To make it safe (85 per cent) we would need [more throughput / less scope by this much]. Here is the range and the trade-off; the call on what to commit is yours."

## Failure modes and anti-patterns

1. **Committing to the 50th percentile.** A P50 date is a coin flip, yet it gets quoted as the plan. Spot it: the committed date equals the "most likely" or average outcome. Fix it: commit at the 85th percentile by default, reserve the 95th for high-stakes dates, and label the 50th as internal only.
2. **Forecasting from story points or average velocity.** Points correlate poorly with time, and an average produces a single number with no probability. Spot it: the forecast is one date with no range, or the input is velocity in points. Fix it: forecast item count with Monte Carlo and report a range.
3. **Too little or stale history.** Fewer than six sprints, or data from a different team or kind of work, gives a confident-looking but unreliable forecast. Spot it: the window is short or predates a big change. Fix it: widen the window if valid data exists, otherwise use a reference class and say so.
4. **Ignoring scope growth.** The forecast models team speed but assumes scope is fixed, so the first split silently breaks it. Spot it: a single scope number with no high end. Fix it: model a low-to-high scope range and show its effect on the date.
5. **The one-and-done forecast.** Run once, quoted for months, never updated as reality moves. Spot it: no re-forecast cadence. Fix it: re-run every sprint and treat a moved forecast as new information, not a failure to hide.

## Quality bar

Before handing over a forecast, confirm: it is a range with probabilities, never a single date; the input is completed item count from at least six sprints or a clearly labelled reference class, not story points or a guessed velocity; scope is modelled as a low-to-high range and its effect on the date is shown; the simulation used enough trials (about ten thousand) for stable percentiles; the reported confidence level fits the decision, with the 85th percentile the default and the 50th marked internal-only; a Little's Law check confirms the implied throughput is one the team has actually sustained; the forecast is dated, states its scope and window, and names a re-forecast cadence; and any move to commit a date is left to a person, with the trade-off for an earlier date made explicit. No throughput figure, percentile or date in the output is invented; each traces to the team's data or a named reference class.

## Tool appendix

- **ActionableAgile, and Monte Carlo plugins for Jira and Azure DevOps**: run the simulation from your tracker's completed-item history. Sample the last 8, 12 or 26 weeks, use item count rather than points, and read the 85th percentile for external dates. Re-run each sprint.
- **Troy Magennis's "Throughput Forecaster" and SimResources spreadsheets (FocusedObjective)**: free Monte Carlo spreadsheets that forecast from a low and high scope and a throughput sample; good when you have no plugin and want to see the mechanics.
- **A spreadsheet or a few lines of code**: Monte Carlo needs only random sampling with replacement and a histogram, so it runs locally at no API or token cost; there is no reason to pay for a tool to get started.
- No tool removes the need for honest inputs. A forecast is only as good as the throughput history behind it, and no simulation can fix data from a team or a kind of work that no longer matches the future.

## Sources

- Daniel Vacanti, "When Will It Be Done?" and "Actionable Agile Metrics for Predictability" (flow metrics, Little's Law as WIP = throughput x cycle time, percentiles over averages, the 85th percentile default, 50 to 95 more than triples the range, the Rule of Five at 93.75 per cent, right-sizing rather than estimating, story points uncorrelated with cycle time). Last verified 11 November 2026.
- Scrum.org, "Create faster and more accurate forecasts using probabilities" (a probabilistic forecast as a range with probabilities, Monte Carlo over thousands of trials, 50/70/85/95 reference lines, use estimates until you have history then switch). scrum.org. Last verified 11 November 2026.
- Troy Magennis / Focused Objective, "Forecasting Using Data" (sampling throughput, how little data is needed to start, modelling low and high scope, risk). Last verified 11 November 2026.
- ADO Analytics, "Monte Carlo forecasting for agile teams" (about ten thousand trials, at least six sprints of history, item count over points, P50 internal, P85 stakeholders, P95 high-stakes, re-run each sprint). Last verified 11 November 2026.
- Bent Flyvbjerg and Alexander Budzier, "Why Your IT Project May Be Riskier Than You Think", Harvard Business Review, 2011 (1,471 projects; 27 per cent average cost overrun; one in six a black swan at 200 per cent cost and almost 70 per cent schedule overrun; fat tail; reference class forecasting; break projects down). arxiv.org/abs/1304.0265. Last verified 11 November 2026.
- Daniel Kahneman and Amos Tversky, the planning fallacy (systematic underestimation of time and cost; the outside view), as summarised by PMI and QSM. Last verified 11 November 2026.
- Mike Cohn / Mountain Goat Software, "Agile planning" (forecast from a velocity range rather than a single number; promise a range; revise each sprint). mountaingoatsoftware.com. Last verified 11 November 2026.

---
1.0.0, 11 November 2026: first release. Use, adapt and share this skill under CC BY 4.0: credit Afeez Adebayo, link afeezadebayo.com and the skill's download page. This is decision-support guidance, not a substitute for your own delivery judgement.