Key Takeaways
- Rolling up three teams’ optimistic dates and picking the latest one does not cancel the optimism, it compounds it, because each single date hides a whole range of sprint-to-sprint outcomes.
- The release date that matters is when the last and least predictable team finishes, so a combined plan is only ever as done as its slowest contributor.
- Capacity-blended forecasting replaces per-team date guesses with each team’s real throughput, keeping every team’s distribution intact instead of averaging them into one fictional team.
- Release Management, Roadmaps, Portfolio PPM & Timeline reads every contributing team’s throughput and runs thousands of simulated futures across the combined backlog to produce one p50, p85, and p95 date range, with p85 the usual planning date.
- Because each team’s throughput stays separate, the forecast shows which team is dragging the p85 date out, turning the status meeting from blame into a capacity decision you can watch update live inside Jira.
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. Release Management, Roadmaps, Portfolio PPM & Timeline 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 Release Management, Roadmaps & Portfolio free for 30 days on the Atlassian Marketplace.
