Capacity-Blended Multi-Team Forecasting (Monte Carlo): How It Works
This page explains how Release Management, Roadmaps & Product Portfolio for Jira produces a single probabilistic release date when a Fix Version spans more than one team. It is a neutral reference doc; for the story behind why single-date rollups fail, see the related blog post linked at the bottom.
What "capacity-blended" means
When a release draws issues from several teams (for example frontend, backend, and platform), each team has its own delivery rate. Capacity-blended forecasting models each team's historical throughput — the number of issues it actually completes per sprint or per week — separately, then combines those distributions into one forecast for the whole release rather than averaging the teams into a single fictional team.
How the forecast is built
Per-team throughput history. The app reads each contributing team's completed-issue history at a consistent granularity (per sprint or per week).
Monte Carlo simulation. It runs thousands of simulated futures, each one randomly sampling from what every team has actually delivered before. Randomness is constrained by real history, not optimism.
Roll-up into one date. Each simulated run resolves the entire remaining scope across all teams; the spread of outcomes becomes the release forecast.
Percentile output. Results are expressed as p50 / p85 / p95 confidence dates for the combined release — one number set, not one date per team.
Reading the result
The p85 date is the commonly used planning date: the release finishes on or before it in roughly 85% of simulations. Because the model keeps each team's distribution intact, you can also see which team is the constraint pulling the later percentiles out — the slowest or least predictable team, not the sum of all teams, sets the date.
The combined release is only as "done" as its bottleneck team. Adding more scope to a fast team does not move the date if a different team is the constraint.
Prerequisites
Each contributing team has enough completed-issue history for a stable sample (a handful of sprints is usually enough).
Issues are assigned to the release's Fix Version so they are inside the forecast scope.
Throughput is read at a consistent cadence across teams.