Every project-management tool asks you to type in a target date. Every product manager wonders where that number came from. It's almost always astrology: last quarter's rollover plus a stakeholder's flinch plus the number that made the executive stop asking.
Ithura now shows a Monte Carlo delivery forecast on every module and sprint header instead. A live P50 / P85 / P95 band computed from your team's real 90 days of throughput. Drag scope in, the band slides right. Drag it out, the band slides left. The number is defensible because it is derived from the same days the team actually shipped.
Where to look for it. Open any module (epic) or any sprint. The forecast pill sits at the right of the header, showing the P85 date by default. Hover for the full P50 / P85 / P95 band, the count of open tasks, the average throughput, and the size of the history the sampler drew from.
Why bootstrap sampling
Real team throughput is bursty in ways parametric models miss: two-week planning cycles, quarter-end pushes, holiday quiet periods, the one Friday everyone shipped in a row. A Poisson or Gaussian model smooths those patterns away and returns a forecast that's biased to the middle.
Instead, the sampler runs 10,000 futures, each drawing a random daily throughput from the team's actual last 90 days, and stops each simulated future when the remaining scope is done. The distribution of "days needed" across all 10,000 runs sorted, and the P50 / P85 / P95 boundaries become the returned dates.
This is the technique ActionableAgile (the paid Jira plugin) and every credible flow-metrics tool uses. What's new here is shipping it native in the tracker, on every module and sprint, live, on every workspace, no plugin.
How to read the pill
- P50: the date half of the simulations finished by. Your "most likely" date. Do not commit here.
- P85: what most teams cite as a commit-able date. Land dates here. This is what shows on the pill by default.
- P95: the widest plausible finish. Useful for scenario planning and answering "worst case?" honestly.
What the "based on N days" note means
The pill's tooltip carries the count of days of history the sampler used. Under 14 days of history, the number is soft, and the sampler flags it as such. Ship a few more issues, come back, watch the band tighten.
API
For dashboards, reports, or your own automation:
GET /workspaces/{slug}/projects/{projectID}/modules/{moduleID}/forecast/
GET /workspaces/{slug}/projects/{projectID}/cycles/{cycleID}/forecast/
{
"scope": "module",
"remaining_issues": 18,
"p50": "2026-10-03T00:00:00Z",
"p85": "2026-10-14T00:00:00Z",
"p95": "2026-10-22T00:00:00Z",
"history_days": 90,
"avg_throughput": 2.1,
"samples_used": 10000
}The sampler runs inline in the request, ~2ms on realistic histories. Cheap enough for a dashboard to poll every minute.
Where it goes next
- Weighted by estimate points. v1 counts each issue as one. v2 weights by the project's estimate scale so a 5-point epic doesn't sample the same as a 1-point tweak.
- Per-team throughput history. v1 is project-scoped. v2 breaks history out per team so a per-team sprint forecast draws only from that team's shipping record.
- Every plan branch scored. When we ship Plan Branch & Merge (the "what-if mode" for roadmaps), each branch will render its own forecast band automatically. "Simulate the layoff scenario" becomes a real button.
Related
- docs/features/forecasts, the full technical description.
- docs/sovereign. The forecast runs entirely on your Postgres. No AI service, no cloud dependency.