Monte Carlo forecasting: dates and ranges from your own history

Monte Carlo forecasting applies Monte Carlo simulation to questions about the future. A model draws uncertain inputs at random, calculates an outcome for each draw, and repeats this many times. The collection of outcomes shows both the likely range and how likely each part of it is.

Five things define it:

Running a simulation does not show that the model describes the future well. It only works out what the assumptions imply.

1. 1

   Ask a question the model can answer. How long will these 40 items take? fixes the scope and forecasts time. How many items can we finish in six weeks? fixes the time and forecasts scope. They are different forecasts.

2. 2

   Pick the inputs. For delivery, that is usually weekly throughput. For a business model, it might be units sold, margin per unit and fixed costs. Decide which quantities vary and which stay fixed, and write it down.

3. 3

   Run one trial. Draw values at random from the inputs and calculate the outcome once.

4. 4

   Repeat. Thousands of trials build up a distribution of outcomes.

5. 5

   Summarize. Report percentiles, the probability of meeting a threshold or a chart of results.

The random draws do not make the forecast arbitrary. They explore the combinations the inputs allow. But a plausible chart still needs checking, because a simulation will faithfully calculate the consequences of poor assumptions.

An illustrative team finished 4, 6, 3, 7, 5, 0, 6 and 5 items in its last eight weeks, an average of 4.5 a week. It has 40 items left.

To simulate one future week, pick one of the eight numbers at random; the same number can come up more than once. To simulate six weeks, do it six times and add them up. One trial might draw 5, 3, 6, 0, 7 and 4, giving 25 items. The next will differ.

For the 40-item question, keep drawing weeks until the running total reaches 40, and record how many weeks it took. Run that 100,000 times and count:

Dividing 40 by the 4.5 average gives about 9 weeks, which only around 60% of trials meet. A team that wants roughly 85% confidence would plan for 11 weeks. These figures show the mechanics only; they are not a forecast for a real team.

Input choice is where most of the judgment lives. Three options:

Before choosing a history window, ask whether it describes a comparable system: the same people, workflow, type of work, definition of done and dependencies. Write down why you chose it, rather than always using everything available.

Keep real zero weeks when they belong to the process, such as a holiday shutdown. Check whether a zero is real or a missing record; treating them the same builds a data problem into the forecast.

Drawing every input independently can leave out relationships that matter:

Correlated sampling and block resampling handle these cases. The point is to notice when shuffling would break a real pattern.

Find out what the horizontal axis measures first, then whether the chart shows how many trials landed in each bucket (a histogram), the share finished by each point (a cumulative chart) or individual simulated paths. Only then read the probability labels.

In the 40-item example, the labels read:

Picking a later date is a risk decision, not proof that the later date is certain. Keep the remaining probability in the message.

Fixed-date questions run the other way. How many items will we finish in six weeks with 85% confidence? asks for a number that 85% of trials meet or beat, which is the low end of the quantity distribution. In the example, 85% of six-week trials finished at least 22 items, while the middle trial finished 28. Plain language helps: in this model, 85% of trials finish at least 22 items is harder to misread than P85: 22.

Monte Carlo is a way of running a model, not a replacement for every other method:

Monte Carlo and sensitivity analysis work well together. The simulation produces the range; sensitivity analysis explains what drives it, so a wide range does not arrive without a reason.

Compare like with like. A fixed-scope date forecast should be compared with another fixed-scope forecast, not with a fixed-date quantity forecast.

Kanban teams usually sample throughput, the number of items finished per day or week, because it describes the whole delivery system rather than one person's effort. Make these choices explicit:

• Finish line: Which workflow event counts as done. Development complete and available to customers answer different questions.
• Time unit: Days or weeks, used the same way throughout.
• Work included: Features, defects, service requests or a mix.
• Remaining scope: Which items are in the forecast and how new ones will be handled.
• Operating assumptions: Expected staffing changes, interruptions and dependencies.

Do not multiply a typical cycle time by the number of items left. Several items move at once, so a throughput forecast reflects the system better than a one-after-another sum. Little's Law explains why.

Check the work mix too. If the remaining items are unusually large or full of dependencies, ordinary past weeks may not be a fair guide. Split the work, adjust the model or say so plainly. Several flow metrics tools build these forecasts from board data.

Scrum teams can sample throughput or velocity per Sprint and express the forecast in Sprints. Match the interval to how work is really recorded. If completions are logged in a batch at the end of each Sprint, a daily model will misread the pattern.

Bring the forecast, its assumptions and the decision together. A Product Owner deciding on a release can compare the full scope with a smaller scope option. Before relying on the chart, ask:

• Scope: Is the forecast for every listed item or one release?
• History: Does the past data reflect the team and workflow expected ahead?
• Done: Does finished mean the same in the data as in the stakeholder's head?
• Triggers: Which scope changes or events would call for a new forecast?
• Value: Is the conversation still about useful outcomes, not just item counts?

Finishing more items does not prove that more value was delivered. Keep the Product Goal in view alongside the numbers.

In finance, Monte Carlo simulation explores how uncertain sales, costs and payment timing affect results. An illustrative business forecasting its cash position might connect uncertain sales, customer payment delays and operating costs, then ask how often cash falls below a set floor.

It is most useful when the decision depends on the range, not the midpoint:

Agree in advance which probability level matters and why. A costly external commitment may justify a later, safer date. A reversible internal plan can live with more uncertainty.

1. 1

   Write the decision question. The outcome, scope, horizon and threshold, and what someone will do differently after seeing the result.

2. 2

   Select and inspect the data. Look for missing records, changed definitions, duplicates and process changes. Write down why the window fits.

3. 3

   Document the model. Fixed quantities, uncertain inputs, links between inputs and exclusions.

4. 4

   Run it and check single trials. Make sure individual trials behave sensibly before reading the totals. Look into impossible outputs and unit mix-ups.

5. 5

   Check stability. Rerun or add trials to see whether the reported figures move. Keep the settings so the run can be repeated.

6. 6

   Challenge key assumptions. Try plausible alternatives for scope, inputs or conditions, and see whether the decision changes.

7. 7

   Communicate and update. Report the range, assumptions, remaining risk and what would trigger a new forecast.

A useful sentence for reports: using the last eight weeks and unchanged scope, 85% of trials finish by week 11; the model excludes the planned move to the new platform.

Validation asks two separate questions. Does the software implement the intended model correctly? Does that model forecast the real outcome usefully? A repeatable calculation answers the first, not the second.

Keep a simple forecast register:

Judge over many forecasts, not one. A single miss does not disprove an 85% forecast, but a run of misses with the same kind of work suggests the model needs different inputs. Do not adjust old assumptions to make past results look better.

1. 1

   Trusting trial count over data. A million trials of the wrong history are still wrong.

2. 2

   Quoting a percentile as a promise. 85% means about one time in seven it runs later.

3. 3

   Reading the quantity forecast the wrong way. The 85% figure for how many items is the low end, not the high end.

4. 4

   Mixing finish lines. History measured to dev complete, forecast quoted as live for customers.

5. 5

   Ignoring scope growth. New items arriving during the forecast period push the date out.

6. 6

   Picking the comfortable answer. Choose the probability level before seeing the chart, not after.