How to Forecast a Delivery Date from Jira Data

Updated 1 November 2026 · All guides

The short answer

To forecast a delivery date from Jira, measure how many issues the team actually finishes each week, subtract the rate at which new work arrives, and divide the remaining work by what is left. Use slow and fast weeks to give a date range, adjust for leave and shared people, and say how confident you are based on how complete the Jira data is. Then watch overdue and blocked work, because they move the date before throughput does.

Step 1: Check the data is good enough to forecast

A forecast is only as good as the data behind it. Before calculating anything, run these searches on the open work in the project (replace ABC with your project key):

Open work with no estimate:
project = ABC AND statusCategory != Done AND "Story Points" is EMPTY

Open work with no due date:
project = ABC AND statusCategory != Done AND duedate is EMPTY

Open work with no assignee:
project = ABC AND statusCategory != Done AND assignee is EMPTY

The story points field name varies between Jira sites (team-managed projects often call it "Story point estimate"). Divide each count by the total open work to get a coverage percentage. As a rule of thumb, which is also what Exentras uses:

• High confidence: at least 80% of work estimated, and at least half of it with due dates and assignees.
• Medium confidence: 40–79% of work estimated.
• Low confidence: under 40% estimated. Treat any date as a planning gap, not a commitment.

Step 2: Measure throughput

Throughput is the number of issues finished per week. Count it for each of the last 8–12 weeks:

Issues finished in the last 12 weeks:
project = ABC AND statusCategory = Done AND resolved >= -12w

If your workflow does not set a resolution, use the status history instead:
project = ABC AND status CHANGED TO Done DURING (-12w, now())

Note the slowest week, the fastest week and the median. Use the median rather than the average: one unusually good or bad week should not move your forecast. Exclude weeks that are not representative, such as a holiday shutdown.

Step 3: Count remaining work and scope growth

Count the open issues in scope for the release or project. Then count how many new issues were created per week over the same period:

Remaining work:
project = ABC AND statusCategory != Done AND fixVersion = "2.0"

New work added in the last 12 weeks:
project = ABC AND created >= -12w AND fixVersion = "2.0"

Scope growth is the step most forecasts skip, and the most common reason dates slip. If the team finishes 12 issues a week but 3 new ones arrive each week, the backlog only shrinks by 9.

Step 4: Calculate a date range

For each of the slow, median and fast weeks: weeks remaining = remaining work ÷ (throughput − weekly scope growth).

The range looks wide, and it should: it is the honest answer today. It narrows as remaining work shrinks and throughput settles. Report the median date with the range, never the fast-week date on its own.

Step 5: Adjust for capacity

Throughput from past weeks assumes the same team will be available. Check what will change:

• Approved leave. If two of six engineers are away for two weeks, the team loses roughly a third of its capacity for those weeks, which pushes the example's median out by about a week, to 8 February 2027.
• Shared people. Someone allocated to three projects will not deliver at last quarter's pace if one of the others is in crisis.
• Team changes. New joiners usually lower throughput for a few weeks before they raise it.

Step 6: Watch the signals that move the date

Throughput is a lagging measure. These leading signals tell you a date is about to slip before the weekly count drops:

• Overdue work: issues past their due date. project = ABC AND statusCategory != Done AND duedate < now()
• Blocked work: issues flagged or in a blocked status for more than a few days.
• Schedule performance: work completed against work planned by now. Below plan for two weeks running is a trend, not noise.
• Overloaded people: anyone allocated beyond their capacity across projects.

Which forecasting method to use

Common mistakes

• One date, no range. The date becomes a promise, and the uncertainty is discovered when it is missed.
• Ignoring scope growth. The backlog never shrinks as fast as the team works.
• Forecasting from story points with low coverage. If half the work is unestimated, the points total is wrong by an unknown amount.
• Treating the sprint commitment as the forecast. A commitment is a goal; a forecast is what the data says will happen.
• Forecasting once. Recalculate every week. The trend in the date is as useful as the date.

How Exentras forecasts delivery

Exentras syncs your Jira Cloud projects read-only and keeps a forecast for each one up to date, so nobody has to run these searches by hand. Every project gets:

• A delay risk score from 0 to 100, built from schedule performance, overdue and blocked work, team activity and team allocation, shown as green, amber or red.
• An estimated slip in days.
• A separate forecast reliability rating (high, medium or low) from estimate, due date and assignee coverage, with the reason in plain words, for example "Only 35% of work items contain estimates."

Capacity accounts for approved leave, and the riskiest projects appear in the weekly executive brief. Read more about delivery forecasting or how the Jira connection works.