How to Forecast a Jira Delivery Date You Can Actually Trust

Ask most teams how they forecast a delivery date and you'll hear a version of the same answer: "We look at our past velocity and adjust it by a rough sense of our capacity until the deadline." It's reasonable, it's fast, and it's wrong often enough to burn you in front of a stakeholder. Here's why — and what a forecast you can defend actually needs.

Why "velocity ÷ remaining work" quietly fails

Taking your average velocity and dividing the work that's left by it feels like math, but it hides three assumptions that break in the real world:

• It treats an average as a promise. Velocity is a mean of sprints that were faster and slower. A single date built on the mean says nothing about how wide that spread is — and the spread is the whole risk.
• It assumes next quarter's capacity equals last quarter's. But someone's on leave in three weeks, a new hire is ramping, and two people are half-allocated to another project. Past velocity already baked in a team that no longer exists.
• It ignores the order work has to happen in. If the API has to ship before the UI can, no amount of team capacity moves the UI earlier. Dependencies set a floor that velocity math can't see.

The result is a confident single date with none of the caveats that make it true. When it slips, it looks like you missed — when really the number was never trustworthy to begin with.

What a forecast you can defend actually needs

1. Measure remaining work against real capacity, not average speed

Velocity tells you how fast the team has gone. Capacity tells you how much the team can actually do between now and the deadline — accounting for who's available, time off, and the fact that a sprint already half-elapsed only has half its capacity left to spend. A forecast that weighs the work remaining against that real, forward-looking capacity is far harder to fool than one built on a historical average.

A useful refinement is effective capacity — your team's raw capacity multiplied by how much of what it plans it actually delivers (measured from your own sprint history). A team that reliably finishes 80% of what it commits shouldn't be forecast as if it finishes 100%.

2. Respect the dependencies

The earliest a plan can possibly finish isn't set by capacity — it's set by the longest chain of work that has to happen in sequence. That "critical chain" is a floor: even with infinite people, you can't beat it. A trustworthy forecast checks the capacity-based date against the dependency-based floor and reports the later of the two, because that's the one reality will enforce.

3. Give a range and a probability, not a single date

Delivery is uncertain, so the honest output isn't "March 15" — it's "about an 80% chance by March 15, most likely between March 8 and March 24." That's what a Monte Carlo simulation produces: it runs the plan hundreds of times against the natural variation in your velocity and returns the odds of hitting the target plus an optimistic-to-pessimistic finish window. A stakeholder can make a real decision with a probability and a range. They can't with a false-precision single date.

4. Let it move when reality moves

A forecast made in a spreadsheet is stale the moment scope changes or someone's added to the team. A forecast that reads the live project re-answers the question every time the plan changes — which means you catch the slip while you can still do something about it, not at the deadline.

Putting it together

A delivery date you can put your name on isn't one number. It's remaining work weighed against real capacity, checked against the dependency floor, expressed as odds and a range, and kept live against the actual project. Do that and "will we make it?" stops being a gut call and becomes a defensible answer.

This is exactly what we built Project Commander to do. It reads your live Jira project and produces a delivery forecast the way this article describes — weighing remaining work against your team's real capacity (including effective capacity from your own history), respecting dependencies against the critical-chain floor, and running a Monte Carlo to give an on-target probability and a likely-finish range that updates as the plan changes.