Jira's remaining estimate is a forecast of unfinished effort. It is not necessarily the original estimate minus logged time. When you log or correct work, check the remaining-estimate action and the value that was actually saved.
That distinction explains a common reporting puzzle: time spent changes, but the forecast does not move by the amount someone expected.
The concrete reporting answer is: add time spent to the current remaining estimate, then compare that forecast with the original estimate. Download the worked Jira remaining-estimate CSV to reuse the example below.
Separate the baseline from the forecast
Use three values for different jobs:
- Original estimate records the baseline your team intends to preserve.
- Time spent records logged effort.
- Remaining estimate expresses current expected effort still needed.
If the team discovers that a task needs more work, increasing the remaining estimate can be the honest action. It does not require rewriting the approved baseline.
For a forecast, calculate time spent + remaining estimate. Compare that result with the preserved baseline when you need an effort variance. Atlassian's Time Tracking Report documentation describes its Accuracy value as the difference between that current forecast and the Original Estimate.
Copyable Jira remaining-estimate reporting formula
Use one unit throughout the calculation—hours in this example:
Current forecast = Time spent + Remaining estimate Forecast variance = (Time spent + Remaining estimate) - Original estimate
For Excel or Google Sheets, if original estimate is column B, time spent is C, and remaining estimate is D, copy this into the variance column:
=(C2+D2)-B2
Positive variance means the current effort forecast is above the baseline; negative variance means it is below. Manual corrections already affect the saved remaining estimate, so do not add them to the formula a second time.
Worked table: logging, correcting, editing and deleting work
Consider a synthetic issue with an original estimate of 20 hours, six hours already logged, and 14 hours remaining. The team logs work, discovers more scope, corrects the worklog, and later deletes it. Every row is the saved state after the named action.
| Action | Original estimate | Time spent | Remaining estimate before logging or action | Remaining estimate after logging or action | Manual corrections | Edited or deleted worklogs | Current forecast | Forecast variance |
|---|---|---|---|---|---|---|---|---|
| Starting state | 20h | 6h | 14h | 14h | — | — | 20h | 0h |
| Log 3h and reduce remaining by 3h | 20h | 9h | 14h | 11h | — | Added 3h | 20h | 0h |
| Re-estimate unfinished work | 20h | 9h | 11h | 15h | +4h | — | 24h | +4h |
| Edit the 3h worklog to 2h; manually preserve the forecast | 20h | 8h | 15h | 16h | +1h | Edited 3h → 2h | 24h | +4h |
| Delete the corrected 2h worklog and add the deleted time back | 20h | 6h | 16h | 18h | — | Deleted 2h; add-back selected | 24h | +4h |
Download the worked example as CSV. The numeric columns use hours so you can import the file without first converting Jira duration strings.
The first worklog records expected progress: 9h spent + 11h remaining = 20h, so variance remains zero. The manual re-estimate then adds four hours of newly discovered effort: 9h + 15h - 20h = +4h.
Editing the worklog from three hours to two corrects the record of past effort. In this example, the user also raises remaining effort from 15 to 16 hours to preserve the team's 24-hour forecast. Deleting that two-hour worklog uses Jira's add-back option, returning time spent to six hours and remaining to 18 hours. The forecast is still 24 hours because the correction changed the record, not the team's current expectation.
These are illustrative saved states, not recorded output from a Jira test. They demonstrate explicit choices. Your Jira screens, permissions, time-tracking provider, automation, and selected remaining-time actions determine the actual saved values.
Check what happens when a worklog is edited or deleted
Atlassian's time-logging documentation describes separate edit and delete actions, their permissions, and adjustments to remaining time. It also advises manually correcting remaining time when the result is not what you expect.
A worklog correction can affect the record of past effort without describing a new discovery about unfinished work. For example, changing an accidentally entered three-hour log to two hours corrects the past. The person doing the task must still decide whether the remaining forecast should change.
Do not assume that deleting a worklog reverses every other edit made around the same time. Inspect the actual saved values and the relevant history.
Reproduce the behavior with a disposable sample issue
Use a nonproduction example and record your Jira deployment, project type, time-tracking provider, and displayed options. Avoid experimenting on a live reporting baseline.
- Record original estimate, total time spent, and remaining estimate.
- Add a small worklog using a chosen remaining-time option.
- Reopen the issue and record all three saved values.
- Edit that worklog and record the selected adjustment and result.
- Delete the sample worklog with an explicit remaining-time decision.
- Compare the final state with what you expected to restore.
If an automation rule or app also changes estimates, include it in the investigation. A result can be correct for the combined workflow while differing from the dialog action alone.
Keep the findings as a short team note. Screens and wording can differ across environments; a recorded local example is more useful than an assumed universal button sequence.
Diagnose a surprising remaining total
| Observation | First thing to inspect |
|---|---|
| Remaining effort never decreases | Logging choices, team practice, and automation |
| Forecast jumps after a correction | Worklog edit and saved remaining value |
| Parent total differs from children | Hierarchy rule, direct parent values, and included issues |
| A finished issue still has remaining time | Actual completion and whether the forecast was maintained |
| An empty value appears as zero in a report | Export or reporting treatment of missing data |
An empty field means the forecast may be unknown. Converting it to zero can make a report appear more complete while understating the remaining work.
Report forecast changes without rewriting history
For each reporting date, capture the issue scope, baseline, logged effort, remaining estimate, and a short explanation of material changes.
A useful update is: “The baseline remains 20 hours. Eight hours are logged and 16 remain, so the current forecast is 24 hours. The team added four hours to the prior forecast after reviewing the integration work.”
That final explanation is appropriate only when the team has confirmed it. A spreadsheet cannot infer the reason merely from the change in totals.
To retain the same calculation across repeated checkpoints, use the four-sprint continuous-forecasting example. It keeps scope events, estimate revisions, worklogs, and remaining-effort changes in separate columns.
TimePillar can be evaluated as a way to review related Jira time data. Whatever report you use, retain the source values and a clear rule for missing estimates so a changing forecast remains explainable.