Key Takeaways
- A committed release date is often wrong the day it is set, because roadmaps draw straight lines while people estimate optimistically; the fix is to replace estimation with simulation.
- Monte Carlo forecasting answers a better question than the usual when-will-this-be-done, namely the probability of finishing by a given date, using your team’s real historical throughput from Jira.
- The simulation produces three planning numbers: p50 (a coin flip, useful internally but risky to promise), p85 (the date most teams should commit to), and p95 (a conservative date for a customer or board).
- Release Management, Roadmaps, Portfolio PPM & Timeline runs the simulation natively in Jira Cloud on Atlassian Forge against live issue data, so adjusting scope on the board recalculates the forecast with no exports or stale spreadsheets.
- The forecast accounts for capacity, including PTO and holidays, and exists to make uncertainty visible, so when scope creeps you can watch the p85 date move and decide with data whether the new feature is worth the slip.
Every engineering leader has sat in that meeting. The one where a release date everyone agreed to three months ago has arrived, and the work hasn’t. You walk through the blockers, the scope that grew, the engineer who was out for two weeks. Everyone nods. And somewhere in the room, a little trust quietly leaks out of the roadmap.
Here’s the uncomfortable part: the date was probably wrong the day it was set. Not because anyone lied, but because roadmaps draw beautiful straight lines and humans are chronically optimistic estimators. We picture the version of the project where nothing goes sideways. Optimism bias is baked into how we plan, and no amount of “let’s be realistic this time” in a planning meeting fixes a method that was never grounded in data.
Stop estimating the future. Simulate it.
There’s a better question than “when will this be done?” It’s “what’s the chance we finish by a given date?” That’s the question Monte Carlo simulation answers, and it’s the engine behind probabilistic release forecasting.
The idea is simpler than the name suggests. Instead of asking your team to estimate the future, you let your team’s actual past do the talking. Release Management, Roadmaps, Portfolio PPM & Timeline reads your real historical throughput (how many issues you’ve genuinely completed, sprint after sprint, straight from Jira’s issue history) and runs thousands of simulated futures against the work that’s left. Each run samples from how your team has truly performed. Aggregate them, and you get a full distribution of likely finish dates.
What p50, p85, and p95 actually mean
Out of that distribution come three numbers that will change how you talk about dates:
- p50: a 50/50 coin flip. Half your simulated futures finish by this date. Useful internally, risky to promise.
- p85: the planning sweet spot. 85% of outcomes land on or before it. This is the date most teams should actually commit to.
- p95: your conservative, sleep-at-night date. The one to give a customer or a board.
Notice what just happened. “We’ll ship September 15th” (a single date defended by gut feel) becomes “there’s an 85% chance we ship on or before September 22nd.” One of those statements collapses under the first hard question. The other invites a real conversation about release planning in Jira: do we like that confidence level, or do we adjust scope, capacity, or the date until we do?
It’s not a spreadsheet. It’s native Jira.
Forecasting like this has existed for years, in standalone tools and heroic spreadsheets. The problem was always the same: the data lived in Jira and the forecast lived somewhere else, so the two drifted apart within a single sprint. Release Management, Roadmaps & Portfolio runs the simulation natively inside Jira Cloud on Atlassian Forge. The throughput it uses is your live issue data. Adjust scope on the planning board and the forecast recalculates: no export, no copy-paste, no stale tab.
It also respects how teams really work. The simulation accounts for capacity (PTO and holidays included) so a forecast doesn’t quietly assume everyone is at their desk 365 days a year. If you want the mechanics of how the model samples throughput and reads the percentiles, we’ve written it up in a plain-English guide to how probabilistic forecasting works.
A forecast is a decision aid, not a weapon
One caution worth stating plainly: a probabilistic forecast exists to make uncertainty visible, not to club a team into guaranteeing a percentile. The value isn’t the number: it’s the conversation the number unlocks. When scope creeps mid-release, you can watch the p85 date move and decide, with data, whether the new feature is worth the slip. That’s the difference between managing a release and apologizing for one.
The missed-deadline meeting doesn’t have to be a recurring event on your calendar. Swap optimism for evidence, and the conversation changes from “why did we slip?” to “here’s the date we can defend, and here’s exactly how confident we are.”
Try it on your next release
That forecast is exactly what feeds the PI planning confidence vote, keeping that committed release date live after the vote means tracking scope, dependencies, and capacity against it in real time.
Run a probabilistic forecast on your next Jira Fix Version, free for 30 days. See your real p50/p85/p95 dates in minutes: try Release Management, Roadmaps & Portfolio free on the Atlassian Marketplace, or explore more release planning guides and resources.
