🚀 Agile Monte Carlo Charts 1.1: forecasts on hours, with the math showing

[#1]

If you run Monte Carlo forecasts in Jira, you already know the pitch: a confidence range instead of a single optimistic date. You also know the two places it tends to stall before stakeholders trust it.

Wall one is the estimation field. Teams that plan in hours and days, not story points, get asked to translate their real planning unit into one they don't use.

Wall two is the throughput input. The chart hands you a curve, but the sample behind it sits behind the chart, not in front of it. "Which items are you counting?" lands as "trust the simulation."

Agile Monte Carlo Charts 1.1 drops both. Time spent & remaining joins the estimation field list, and every throughput input now expands into a breakdown, plus the raw issue list.

This article walks through both changes and what they mean in a real sprint review.

🕒 Forecast on the units your team actually plans in

Agile Velocity Charts and Agile Burnup Burndown Charts in our suite already accept Time spent & remaining as an estimation field. It's the integrated time field that combines the original estimate, time logged, and remaining estimate into one running number, so the chart reflects what the team is already maintaining in Jira.

Monte Carlo Charts was the one report that didn't accept it, which left time-tracking teams with a frustrating gap: velocity in hours, burnup in hours, and forecast in something else.

From this release, the Monte Carlo charts accept Time spent & remaining on the same pattern as the other charts. Pick the field in the chart's calculation settings, and the simulation runs on the data your team is already keeping current – no parallel story-point system to maintain, no translation step where assumptions quietly drift.

The field works exactly the way it does in our other charts. It picks the right time component per issue based on the issue's status:

• To Do uses Time remaining;

• In Progress uses Time spent + Time remaining;

• Done uses the Original estimate (with an optional override to count only actual logged time).

One running number per issue, on the same basis that the team already plans in.

What changes in practice: a delivery lead on a twenty-person team running two-week sprints in hours can answer "when will the release be done?" with a probabilistic range built from the same fields the team plans in. The forecast stops being a separate artifact you defend on its own terms.

🔍 The data behind the curve, one click away

Probabilistic forecasting's whole pitch is that it embraces uncertainty instead of hiding it. Which is what makes an opaque forecast such an awkward thing to hand a stakeholder – you're asking them to trust uncertainty without showing them the uncertainty's source material.

Until this release, that's what a Monte Carlo chart in our product did. The throughput input drove the curve, but you couldn't expand it to see which sprints, which issues, and which completed work it was actually counting.

What's now in the throughput

The throughput and the alternative throughput inputs each expand into two views:

• a breakdown segmented by whatever grouping you've already chosen on the chart – component, priority, assignee, status, any Jira field;

• a flat issue list of the completed work that fed the calculation.

Both views are collapsed by default. The chart view stays clean for the headline-reading user; the verification view is one click away for the auditor. "Trust the math" becomes "here is the math, audit it yourself."

The change is small in click count and large in conversation quality. The next time a delivery manager fronts a forecast in a portfolio review and gets the inevitable "is that the right sample?", there's a concrete answer: forty-seven issues across twelve sprints, here's the throughput distribution, here's the breakdown by component. The discussion moves from credentialing the chart to debating the inputs, which is the discussion probabilistic forecasting was supposed to be having all along.

✅ Pulling the two together

The release doesn't add a new chart or a new methodology. It removes two specific frictions that quietly pushed Monte Carlo forecasts in Jira away from teams that should have been using them: the assumption that you estimate in story points, and the assumption that you'd take the forecast on faith. With both gone, the same chart now works for hours-based teams and gives any team a way to defend the forecast with the actual data behind it.

Agile Monte Carlo Charts is one option for probabilistic forecasting inside Jira. If your team plans in time, or if your stakeholders ask harder questions than your current forecast can answer, it's worth a look. The same fit applies for enterprise delivery managers defending a forecast to a steering committee – forecasting trust matters more, not less, when the audience is senior.

– The Broken Build team