In Jira, the original estimate is how long you expected the work to take, time spent is the total of all work logged, and the remaining estimate is how much work is still expected. When you first log work, Jira subtracts the time spent from the original estimate to set the remaining estimate. After that, each new log is subtracted from the remaining estimate.
Key takeaways
- Original estimate: the plan. Set it once.
- Time spent: the sum of every worklog on the issue.
- Remaining estimate: what is left, and the one to update as you learn more.
- Accuracy compares time spent plus remaining with the original estimate.
What do the three fields mean?
Jira's time tracking fields
- Original estimate
- The time you first thought the issue would take. On the issue it shows as Estimated
- Time spent
- The total time logged on the issue so far. It shows as Logged
- Remaining estimate
- The time currently expected to finish the issue. It shows as Remaining
Atlassian describes the fields in its documentation on logging time.
How does Jira calculate them?
First log: remaining = original estimate − time spent
Later logs: remaining = previous remaining − time logged
Follow one issue with an original estimate of 8 hours.
| Step | Logged now | Time spent | Remaining estimate |
|---|---|---|---|
| Issue created | 0h | 8h | |
| First worklog | 3h | 3h | 5h |
| Second worklog | 4h | 7h | 1h |
| Third worklog | 2h | 9h | 0h |
The issue took 9 hours against an estimate of 8. The remaining estimate stops at zero, and the time spent keeps counting.
What is estimate accuracy?
Jira's Time Tracking Report has an Accuracy column. Atlassian defines it as the difference between the sum of the Time Spent and Estimated Time Remaining fields, and the Original Estimate field.
Accuracy = (time spent + remaining estimate) − original estimate
Example: 7h spent + 1h remaining − 8h original = 0h, which is on estimate
Example: 9h spent + 0h remaining − 8h original = 1h over
How to read that report is covered in the Jira time tracking report.
Which estimate should you change?
The remaining one. The original estimate is a record of what you believed at the start. Change it and you lose the ability to learn from the difference.
Do
- Set the original estimate before work starts
- Update the remaining estimate when the work turns out bigger or smaller
- Log time as you go, so time spent stays current
- Compare original with actual at the retrospective
Do not
- Rewrite the original estimate to match what happened
- Leave the remaining estimate at zero on unfinished work
- Log time in one lump at the end
- Treat an overrun as a failing by the person
What happens when a worklog is edited or deleted?
When you delete a worklog, Jira asks whether to adjust the remaining estimate. You can let Jira add the time back or set a new figure. When you edit a worklog, the earlier values are still used in the calculation, so check the remaining time and correct it by hand if it is not what you expect.
This is one reason estimates drift on busy issues. More causes are in Jira worklogs explained.
How do units affect the numbers?
Jira reads 1d as a working day and 1w as a working week. The defaults are 8 hours in a day and 5 days in a week.
| Entered | Means, by default |
|---|---|
| 1d | 8 hours |
| 3d 4h | 28 hours |
| 1w | 40 hours |
This matters when you export. Atlassian notes that an original estimate of 3 days and 4 hours is exported as 100,800 seconds, which is 28 hours, because Jira counts each day as 8 working hours. If you divide exported seconds by 24-hour days, your totals will be wrong.
What about sub-tasks?
When sub-tasks are enabled, a parent issue can show the combined figures for itself and its sub-tasks. In the Time Tracking Report, a sum column shows each parent's own values plus those of its sub-tasks.
Estimate at one level, either the parent or the sub-tasks. Estimating both counts the same work twice.
Hours or story points?
Original estimate is a time estimate. Many software teams estimate in story points instead and still log hours, because the two answer different questions. See story points vs hours.
Why is time spent so often wrong?
Because it is only as good as the worklogs. Each entry depends on a person remembering to log, picking the right issue and typing the right amount.
Signs your time spent cannot be trusted
- Most worklogs are created on Friday afternoon
- Worklogs come in round numbers: 1h, 2h, 4h, 8h
- Finished issues with an estimate show no time spent
- One catch-all issue holds a large share of the hours
How does BirdsEye keep time spent accurate?
BirdsEye supplies the time spent side automatically. Estimates stay in your team's hands.
- Tracked, not typed. Employees pick a Jira issue in the desktop agent and time is recorded while they work.
- Worklogs match tracked time. BirdsEye creates worklogs and keeps them matched, including after a time entry is edited or deleted.
- No double counting. Reconciliation compares tracked time with what Jira already holds, so repeated syncs do not post a second worklog.
- Health you can see. Administrators see worklog health and can retry a failed sync.
With time spent you can trust, the comparison with the original estimate starts to mean something. Jira is available on the Team and Business plans. See Jira time tracking.
Frequently asked questions
What is the difference between original estimate and remaining estimate in Jira?
The original estimate is the first forecast of how long an issue will take. The remaining estimate is the current forecast of the work left, and it changes as work is logged or re-estimated.
Does logging work change the original estimate?
No. Logging work increases time spent and reduces the remaining estimate. The original estimate stays as it was.
Can time spent be more than the original estimate?
Yes. Time spent keeps adding up after the remaining estimate reaches zero. The gap is the overrun.
How is remaining estimate calculated in Jira?
On the first worklog it is the original estimate minus the time spent. On later worklogs, the time logged is subtracted from the previous remaining estimate.