You know the meeting. A release is due, and three teams own pieces of it: frontend, backend, and platform. You go around the room. Frontend says they’re good for the 15th. Backend says “maybe the 18th, depends on the API work.” Platform shrugs and says “end of the month, probably.” You write the dates on a whiteboard, pick the latest one, add a few days of buffer because it always slips, and call it a plan. Then you spend the next three weeks watching it slip anyway.

The spreadsheet rollup feels rigorous. It is not. Stapling three optimistic guesses together doesn’t cancel the optimism out — it stacks it up. And the release date you really care about isn’t the average of your teams. It’s the moment the last and least predictable team finishes its part.

Why summing dates quietly fails

Each team’s “we’ll be done by the 15th” is a single point hiding a whole range of outcomes. Some sprints they close twelve issues; some sprints, interrupted by incidents and code review and the one senior engineer being on PTO, they close five. When you collapse that range into one confident date and then combine three of them, the uncertainty doesn’t disappear — it compounds in the background where you can’t see it. The combined plan looks precise and is almost always wrong in the same direction: too early.

The fix isn’t a better spreadsheet or a sterner planning meeting. It’s the same idea behind probabilistic release forecasting — let the model carry the uncertainty instead of pretending it away — extended to more than one team at once.

Capacity-blended forecasting, in plain terms

Instead of asking each team for a date, capacity-blended forecasting asks each team’s history a quieter question: how much do you actually finish, sprint after sprint? That number — throughput — already contains all the messy reality of meetings, holidays, and rework. Advanced Release Planning & Management for Jira reads every contributing team’s real throughput, keeps each team’s distribution intact rather than mashing them into one fictional average team, and runs thousands of simulated futures across the combined backlog.

Each simulated run randomly samples from what your teams have genuinely delivered before, so the randomness is constrained by evidence, not hope. What comes out the other side isn’t three guesses — it’s one date range for the whole release, expressed as p50, p85, and p95 confidence. The p85 date is the one most teams plan against: the release lands on or before it in roughly 85% of the simulated futures.

The status meeting gets shorter

Here’s what changes the next time you’re in that room. You’re no longer adjudicating whose date to trust. There’s one forecast, and it came from data every team already generated by doing their work. Better still, because the model keeps each team’s throughput separate, you can see which team is dragging the p85 date out to the right. That’s your real constraint — and the uncomfortable truth is that piling more scope onto your fastest team does nothing if a different team is the bottleneck. The combined release is only ever as done as its slowest contributor.

That reframes the conversation from blame to bottlenecks. Do you move scope off the constrained team? Pull in help? Cut a Could-have? Now you’re making a capacity decision with a number attached, and you can watch the forecast move as you do it — all inside Jira, with no exporting velocities into a master spreadsheet that’s stale the moment you save it. If you want the mechanics, our guide to how capacity-blended forecasting works walks through it step by step, and the full picture lives on our Jira release planning hub.

One release, one honest date

Multi-team releases don’t have to be an exercise in optimistic arithmetic. When every team’s real throughput rolls up into a single probabilistic forecast, you stop defending a date you quietly never believed and start planning around one you can actually stand behind.

Ditch the rollup spreadsheets. See your multi-team forecast roll up into one date — explore release planning guides and resources, or try Advanced Release Planning & Management for Jira free for 30 days on the Atlassian Marketplace.

Rob Borges

Rob Borges spent the first half of his career hunting waste as a Lean Six Sigma Master Black Belt and wrangling portfolios as a PMI Portfolio Manager — until he realized the tidiest process on earth still can't out-plan an optimistic human. So he switched sides and became an Agile Coach. These days he helps Kanban, Scrum, and Agile-at-Scale teams trade gut-feel deadlines for flow data, turning "we'll probably ship sometime in Q3" into release dates leaders can actually take to the board. His rule of thumb: hope is not a forecast, but your throughput history usually is.

See Full Bio