How to forecast unfinished Jira work with time in status data

[#1]

One work item is due on Friday. It is currently in Code Review.

Jira shows where it is now, but the team still has two difficult questions:

• How much total time is this work item expected to spend across Development, Code Review, and Testing?
• Based on similar completed work, is it likely to pass through those statuses before its target date?

Sprint velocity and release reports can support team-level planning. But they do not answer this smaller workflow question for each unfinished work item.

The new Forecast capability in Time in Status by SaaSJet uses historical time in status data from comparable completed work to estimate how much total time unfinished work is expected to spend across selected workflow statuses.

It then uses that estimate to calculate a projected end date, compare it with a target date, and highlight work that may finish late.

👉 Explore the Forecast documentation

What Forecast actually predicts

Forecast does not predict an entire project, sprint, or release.

It estimates how much total time an unfinished Jira work item is expected to spend across the workflow statuses you select.

For example, you can forecast the combined time spent in:

• In Progress
• Code Review
• Testing
• Ready for Release

Time in Status examines comparable completed work items, calculates how much total time each one spent across those statuses, and takes the median of those totals.

For unfinished work, the forecast then shows:

• how much time the item has already spent in the selected statuses;
• how much total time similar completed work usually required;
• its projected end date;
• the difference between its projected and target dates;
• the confidence of the forecast;
• the completed reference items behind the calculation.

This connects historical Jira time in status data with a practical forward-looking question:

Is this work item progressing within a normal range, or is it at risk of missing its target date?

Why Forecast compares similar work with similar work

A Bug should not necessarily be compared with a Story. A high-priority customer issue may follow a different timing pattern from routine work. A large work item may require more review time than a small one.

Forecast lets you select Jira fields under Compare by to define what comparable work means for your team.

Depending on your Jira configuration, you might compare work by:

• Work type
• Priority
• Project
• Story points
• Request type
• Parent
• Other eligible Jira or custom fields

If Work type is selected, an unfinished Bug is compared with completed Bugs instead of being mixed with every work type.

This creates a reference class that is more relevant to the item being forecast.

The table also shows the number of reference items and forecast confidence, so the estimate is not presented as a mysterious number. Teams can inspect how much historical evidence supports it.

How historical Time in Status becomes a forecast

The calculation follows a transparent sequence.

First, Time in Status finds completed work items that:

1. belong to the selected historical reference data;
2. meet the configured completion criteria;
3. match the unfinished item on the selected Compare by fields.

For every matching completed item, it adds together the time spent in the selected Forecast statuses.

The median of those totals becomes the expected total time for the unfinished item.

Suppose an unfinished Bug has already spent eight working hours across In Progress, Code Review, and Testing.

Comparable completed Bugs spent a median of 12 working hours across the same statuses.

The forecast uses 12 hours as the expected total. Because the unfinished Bug has already spent eight hours there, approximately four hours remain within the forecasted part of the workflow.

Those remaining hours are projected forward using the selected Work Schedule to calculate a projected end date.

If a Jira Date or Date/Time field has been selected as the Target end date, Forecast compares the two dates and makes the variance visible.

Build the historical reference that fits your workflow

Forecast configurations are created and managed on the Forecasts page in Time in Status.

Instead of rebuilding the calculation for every dashboard, you can save a Forecast configuration and reuse it in the Forecast by Time in Status dashboard gadget.

Each configuration defines four important parts of the calculation.

Completion criteria

Select a specific workflow status or a Jira status category to determine which historical work items are considered completed.

For example:

• Status equals Ready for Release
• Status category equals Done

This lets the forecast reflect what completion means in your workflow.

Reference data

Historical completed work can be selected using:

• a JQL query;
• a rolling period such as the previous 60 or 90 days.

JQL is useful when the reference population needs to follow specific project, work type, label, team, or release criteria.

A rolling period keeps the reference data focused on recently completed work and allows the forecast to reflect newer workflow behavior.

Forecast statuses

Select the statuses that represent the part of the workflow you want to forecast.

Time spent in all selected statuses is summed for every completed reference item.

You could forecast:

• development and review time;
• testing and validation time;
• approval and release preparation;
• the full workflow from In Progress to Ready for Release.

The statuses should match the question you are trying to answer.

Compare by fields

Select the Jira fields used to find comparable historical work.

This prevents unlike work from being grouped into one estimate and makes the resulting reference class more meaningful.

Make the projection reflect actual working time

Four remaining hours do not always mean four calendar hours.

If a work item reaches Code Review late on Friday, four working hours may place its projected end date on Monday rather than Friday evening.

The Forecast by Time in Status gadget can use a Work Schedule that defines:

• working days;
• working hours;
• breaks;
• weekends;
• holidays;
• time zone.

This makes Jira forecasting more realistic for teams that do not operate continuously.

A support team with 24/7 coverage can use a continuous schedule. A development team can use its regular business hours. Regional teams can apply schedules that reflect their actual calendars.

Without this context, a Jira Time in Status forecast may technically calculate elapsed time but still produce a misleading operational date.

See forecast risk directly on a Jira dashboard

The Forecast by Time in Status gadget separates work into Not completed and Completed groups.

Not completed work is expanded by default because those are the items that still require attention.

For each unfinished work item, the table can show:

Current time

How much time the work item has already spent across the selected Forecast statuses.

Expected total

The median total time that comparable completed work items spent across those statuses.

Target end date

The planned date stored in the selected Jira Date or Date/Time field.

Projected end date

The estimated date when the work item is expected to complete the forecasted part of the workflow.

The calculation uses the expected total time, the point when the work item first entered a selected Forecast status, and the selected Work Schedule.

Variance

The difference between the projected end date and the target end date.

This helps teams distinguish work expected to finish within its target from work that may finish late.

Confidence

An indication of how much comparable historical data supports the estimate.

A forecast may have low confidence or be unavailable when there are not enough comparable completed items.

Reference items

The historical comparison group used for the calculation.

Teams can inspect the reference items and their sample size instead of accepting the forecast without context.

Completed work remains visible in the table for reference, but it does not receive new forecast values.

Use Forecast during release planning in Jira

Forecast does not replace a release plan. It adds work-item-level evidence to release conversations.

Suppose several work items still need to pass through Code Review, Testing, and Ready for Release.

A release manager can use those statuses as the forecasted workflow segment and compare each projected end date with a Jira target date.

The resulting table helps the team ask more specific questions:

• Which work items are expected to pass through the remaining statuses on time?
• Which items have already used most of their expected status time?
• Which items are projected beyond their target dates?
• Which forecasts have enough historical evidence to support a decision?
• Which work items need investigation before the release becomes at risk?

Instead of treating every unfinished item as equally uncertain, the team can focus on the items that show meaningful timing risk.

Find sprint risk without calling it a sprint forecast

Forecast can also support sprint conversations when its JQL and reference data are scoped to relevant sprint work.

For example, a Scrum Master could review unfinished Stories and Bugs that still need to pass through Review and Testing.

However, Forecast is not a complete Jira sprint forecast.

It does not predict:

• future scope changes;
• how much new work will enter the sprint;
• team capacity changes;
• dependencies outside the selected statuses;
• the completion rate of the entire sprint.

It forecasts Time in Status for individual unfinished work based on comparable completed work.

That narrower definition is important. It keeps the forecast connected to the historical evidence it actually uses.

Know when a forecast needs more evidence

Not every work item will have a strong historical comparison group.

Forecast can be marked Low confidence or Unavailable when there is insufficient comparable completed work.

This may happen when:

• a new work type has little history;
• too many Compare by fields create a very narrow reference class;
• the rolling period contains few completed items;
• the workflow has recently changed;
• the JQL reference population is too restrictive.

Low confidence does not automatically mean the work item is at risk. It means the team should be careful about relying on the projected value.

The reference class and sample size help explain why the confidence is low and whether the Forecast configuration should be adjusted.

Jira forecasting based on evidence already in your workflow

Teams already generate forecasting evidence every time a Jira work item moves through a status.

Forecast turns that historical time in status data into a forward-looking view of unfinished work.

It does not promise an exact delivery date. It provides a transparent estimate based on:

• comparable completed work;
• selected workflow statuses;
• the median historical duration;
• time already spent;
• real working schedules;
• the target date recorded in Jira.

That gives Scrum Masters, project managers, release managers, and team leads an earlier way to investigate timing risk—before the target date has already been missed.

Forecast is available in Time in Status on the Advanced plan.

👉 Learn how Forecast works

👉 Try Time in Status on the Atlassian Marketplace