Continuous forecasting in Jira means recalculating expected effort at completion from the current issue scope, cumulative time spent, and remaining estimate at a regular checkpoint—while preserving the initial scope as a separate baseline. The core calculation is simple: forecast at completion = time spent + remaining estimate. The useful work is explaining why that result moved.
This four-sprint example separates three causes of forecast movement: scope entering or leaving the report, estimates changing on work already included, and the team's remaining-effort judgment changing as it learns. Routine worklogs that reduce remaining effort by the same amount do not move the forecast.
Download the four-sprint Jira continuous-forecasting CSV. It contains every event behind the summary, with numeric hour columns ready for Excel or Google Sheets.
This is a synthetic pilot, not customer data or output captured from a Jira site. Use it to test whether the method answers a real planning question before standardizing another report.
Keep five values separate
Continuous forecasting becomes confusing when one number is asked to represent both the old agreement and today's expectation.
| Value | Meaning in this example | Why retain it |
|---|---|---|
| Initial scope | The approved issue set and estimates at the pilot start | Preserves the question the team originally answered |
| Scope changes | Estimated effort added to or removed from the report boundary | Explains movement caused by a different body of work |
| Estimate changes | Revisions to the estimate of work already inside the boundary | Prevents re-estimation from being mislabeled as added scope |
| Time spent | Cumulative effort recorded in included Jira worklogs | Records effort already used |
| Remaining estimate | Current expected effort still needed | Supplies the forward-looking part of the forecast |
Atlassian's time-logging documentation distinguishes original estimates, logged time, and remaining time. Its Time Tracking Report documentation defines Accuracy using the difference between Original Estimate and the sum of Time Spent plus Estimated Time Remaining. The ledger below adapts that point-in-time calculation into repeated snapshots.
The historical columns are a reporting convention. They are not a claim that Jira exports one native “continuous forecast” table with these exact fields.
Use four formulas
Keep every value in one unit. This example uses hours.
Current scope estimate = prior current scope estimate + scope added - scope removed + estimate changes on included work Forecast at completion = cumulative time spent + remaining estimate Forecast movement = current forecast at completion - previous forecast at completion Variance versus current scope = forecast at completion - current scope estimate
Also retain forecast at completion - initial scope when stakeholders need the full difference from the original 120-hour approval. Do not use that one result to imply that all 30 hours came from execution: ten hours of net scope growth and five hours of estimate revisions are also visible in the example.
In the downloadable CSV, the calculated columns are J through P. For the first event row after the baseline, these spreadsheet formulas can be copied downward:
J3 = J2+G3-H3+I3 M3 = K3+L3 N3 = M3-M2 O3 = M3-F3 P3 = M3-J3
Four-sprint forecast summary
The program begins with a frozen 120-hour scope. Start with the decision-facing view: how much effort has been spent, how much remains, and where the closing forecast now stands.
| Sprint close | Forecast composition | Forecast at completion | Change from prior close | Variance from initial 120h |
|---|---|---|---|---|
| Sprint 1 | 24h spent + 100h remaining | 124h | +4h | +4h |
| Sprint 2 | 58h spent + 82h remaining | 140h | +16h | +20h |
| Sprint 3 | 101h spent + 50h remaining | 151h | +11h | +31h |
| Sprint 4 | 138h spent + 12h remaining | 150h | −1h | +30h |
Then use a separate reconciliation view to explain how scope membership and estimate changes affected the comparison baseline during each sprint.
| Sprint | Scope added and removed | Estimate changes | Current scope estimate | Forecast variance vs current scope |
|---|---|---|---|---|
| Sprint 1 | 0h added; 0h removed | 0h | 120h | +4h |
| Sprint 2 | 18h added; 6h removed | +4h | 136h | +4h |
| Sprint 3 | 8h added; 0h removed | −2h | 142h | +9h |
| Sprint 4 | 0h added; 10h removed | +3h | 135h | +15h |
The closing forecast rises from 124 to 140 to 151 hours, then falls to 150. That sequence is more useful than saying the team “used 138 of 120 hours.” The final snapshot says that 138 hours are already logged, 12 remain, and the expected total is 150 hours.
The final 30-hour difference from initial scope can also be reconciled: +10h net scope + 5h net estimate revisions + 15h variance versus current scope = +30h. That is the value of retaining the intermediate columns—the total no longer has to carry the explanation by itself.
Read each kind of movement correctly
Sprint 1: learning changes the remaining estimate
The team logs 24 hours and reduces remaining effort from 120 to 96. Forecast at completion stays at 120 because one hour moved from the future column to the spent column for every hour logged.
An integration review then adds four hours to remaining effort. No issue enters the scope, and the preserved scope estimate stays at 120. The forecast moves to 124 because the team now expects more unfinished work.
For the mechanics of logging, editing, and deleting worklogs, use the Jira remaining-estimate reporting guide. This article starts from the saved snapshot rather than repeating those dialog-level cases.
Sprint 2: scope and estimate revisions answer different questions
An unstarted 18-hour item enters the program. Both current scope estimate and remaining effort rise by 18 hours, moving the forecast from 124 to 142. An unstarted six-hour item then leaves, reducing the forecast to 136.
The team revises the estimate of work already included by four hours. That changes the comparison value from 132 to 136, but it does not automatically change this ledger's current expected effort. After 34 hours are logged with a matching reduction in remaining effort, forecast still equals 136. Testing then exposes four more hours of unfinished work, producing the 140-hour close.
This separation matters. Adding an issue, editing an estimate on an existing issue, and revising remaining effort may all change a Jira screen, but they describe different planning events.
Sprint 3: progress can be real while the forecast rises
Eight hours of compliance work enter scope. A two-hour downward estimate revision changes the current scope comparison, and 43 hours of matched progress leave the forecast unchanged at 148. A dependency review adds three hours to remaining effort, so the sprint closes at 151.
The team has logged 101 hours by this point. That does not make the forecast 101 hours. Time spent is the consumed portion; the 50-hour remaining estimate completes the current expectation.
Sprint 4: scope reduction offsets new work found
Removing an unstarted ten-hour optional item lowers the forecast from 151 to 141. A three-hour estimate revision changes the current scope estimate to 135 without changing the expected effort. After 37 hours of matched progress, final verification adds nine hours of remaining work.
The closing forecast is 150 hours: one hour below the prior sprint close, 30 hours above the initial scope, and 15 hours above the current 135-hour scope estimate. All three comparisons are valid, but they answer different questions.
Build the pilot from Jira evidence
Use one project, release, epic, or other stable delivery boundary for four sprints. Do not begin with a portfolio-wide rollout.
- Write the scope rule. Record the JQL, hierarchy rule, issue types, timezone, time unit, and how parent and child values are counted.
- Freeze the initial issue keys and estimates. Save a dated file. A live filter cannot reconstruct the original issue set after membership changes.
- Capture scope events. Record each added or removed issue with event time and the estimate used at that event. For Scrum work, Atlassian's Sprint Report documentation identifies work added after sprint start and documents the report's board and subtask boundaries.
- Capture estimate revisions separately. Preserve the before and after value instead of overwriting the history in the ledger.
- Snapshot cumulative time spent and remaining estimate. Take both from the same issue set and at the same cutoff time.
- Calculate and annotate movement. Ask the delivery owner to explain material changes; do not infer a cause from the sign alone.
- Reconcile at sprint close. Check that the summary can be rebuilt from the issue list and event ledger before publishing it.
A release-scoped saved filter might begin like this:
project = DELIVERY AND fixVersion = "Pilot 1.0" ORDER BY key ASC
Use the filter to retrieve and review the current issue set, not as historical proof that an issue was present at an earlier checkpoint. Atlassian documents Jira search-result export options in its CSV export guide. Preserve the exports you actually use for the forecast.
Define the accounting rules before comparing snapshots
A trustworthy result needs more than correct arithmetic.
| Decision | Example rule for the pilot |
|---|---|
| Parent and child work | Count direct leaf-issue values once; exclude parent aggregates |
| Removed work with logged time | Retain the spent effort in a separate removed-scope line instead of making it disappear |
| Missing original estimate | Mark baseline coverage incomplete; do not convert missing to zero |
| Missing remaining estimate | Treat the forecast as unknown unless the team confirms zero work remains |
| Edited or deleted worklogs | Reconcile the saved time-spent and remaining values at the snapshot |
| Reopened work | Restore a remaining estimate and annotate the event |
| Done issue with remaining time | Investigate before publishing; status and effort forecast disagree |
The synthetic removal events in the CSV use unstarted issues, so no recorded effort leaves the active scope. A real removal after work has begun needs an explicit convention. Otherwise the reported cumulative time can fall and make apparent progress look better simply because a worked item was excluded.
Use the sprint scope and rollover reconciliation guide when you need to classify committed, added, removed, completed, and carried-over work. Use the estimated-versus-actual guide when you need to validate one point-in-time issue rollup. Continuous forecasting connects those snapshots; it does not replace their evidence rules.
Decide whether the pilot earns a permanent report
After four sprints, keep the forecast only if it changed a decision or made an existing decision easier to defend. Review:
- whether baseline and remaining-estimate coverage met a threshold chosen before the pilot—for example, 90%;
- whether every material movement had an identified scope or forecast event;
- whether the same issue set could be reconstructed from the saved evidence;
- whether the forecast gave earlier warning than spent-versus-baseline alone;
- whether maintaining the ledger cost less than the planning confusion it removed.
Do not turn forecast variance into an individual performance score. The result mixes scope decisions, estimation updates, worklog corrections, technical discovery, and delivery progress. It is a project-control signal, not a measure of one person's productivity.
Jira continuous forecasting FAQ
Does Jira have a native continuous-forecasting report?
Jira exposes the underlying time fields and several reports, but this article's longitudinal event ledger is a custom reporting convention. Check the current report available for your project type and plan before assuming it preserves the initial issue set, every scope event, and every historical estimate in one table.
How often should a Jira forecast be updated?
Choose a repeatable decision cadence. Sprint close works for this pilot because it creates four comparable checkpoints. A weekly snapshot may be better for a long release or Kanban flow. Capture an extra event when a material scope decision or re-estimate would otherwise be hidden inside the period.
Does logging time always reduce the forecast at completion?
No. If one hour is logged and remaining effort falls by one hour, spent + remaining is unchanged. The forecast moves when the saved remaining estimate changes by a different amount, scope changes, or the report boundary changes.
Can JQL calculate forecast at completion?
JQL defines an issue set; do not rely on it alone for the longitudinal arithmetic or history in this example. Export the fields for the frozen scope, calculate the totals in a spreadsheet or reporting tool, and retain the dated snapshots and change events.
Should the original estimate be overwritten when scope changes?
Preserve the original approved snapshot if stakeholders need variance from that agreement. Record later scope and estimate changes as events. You may also maintain a current scope estimate, but do not let it erase the historical baseline it is being compared with.