Three time fields. Three numbers that should add up cleanly. They often don’t.
Jira has been shipping the same three time tracking fields since the early 2000s: Original Estimate, Remaining Estimate, and Time Spent. Most engineers I’ve worked with can name them. Most cannot tell you, off the top of their head, which one moves when they log work, which one their manager’s sprint report is reading, or what happens when the three stop agreeing with each other.
I co-founded Planim Time, one of the trackers that writes back to these fields, so I have a slightly obsessive view of how they behave. The version of this post I want to read is the one that explains each field in plain English, with the actual default behaviours and the places they trip people up.
The three fields, in order
Original Estimate is the prediction. Someone (usually whoever picked up the ticket, sometimes a tech lead during refinement) writes down how long they think the work will take. Once set, Jira treats it as fixed. It doesn’t move when you log work. It doesn’t update when the scope changes. It’s the number you committed to at the start, frozen.
Time Spent is the actuals. Every worklog entry on the issue adds to it. You can log a worklog through the Jira UI, through the REST API, or through a tracker that pushes worklogs on your behalf. The total Time Spent is the sum of every worklog ever logged against the issue, minus anything that’s been deleted.
Remaining Estimate is the prediction’s living counterpart. It starts equal to Original Estimate. From then on, by default, Jira decrements it every time you log work, which means if you said the work would take 8 hours and you’ve logged 3, Remaining shows 5. The catch is that “by default” is a choice, and Jira gives you four options on every worklog entry.
What happens when you log work
The Log Work form has a dropdown most people never look at carefully. Its label is “Remaining estimate”, and the four options behind it are:
- Adjust automatically. Remaining drops by the amount you just logged. This is the default.
- Leave estimate unchanged. Remaining doesn’t move, even though Time Spent went up.
- Reduce by amount specified. You manually type how much Remaining should drop by.
- Set to new value. You replace Remaining with a fresh number you’ve decided is more honest.
Each of these is right in different situations. “Adjust automatically” works when your original estimate was correct and the work is going as planned. “Leave estimate unchanged” is what you want when you discover the ticket was scoped wrong and the remaining work hasn’t gone down at all, even though you spent two hours on it. “Set to new value” is what mature teams use during sprint refinement when they realise the original estimate was off by half.
A trap worth flagging: most trackers, including some big ones on the Marketplace, only ever post worklogs with the default “adjust automatically” behaviour and offer no UI for the other three. If your team treats Remaining Estimate as a real number that should reflect reality, that integration is quietly destructive.
When the math doesn’t add up
By the time a ticket is in flight, you might see something like:
- Original Estimate: 8h
- Time Spent: 6h
- Remaining: 5h
Total of Spent and Remaining is 11h, not the 8h you originally committed to. That’s fine. It happens whenever someone bumped Remaining upward because the work turned out larger than expected. Atlassian doesn’t enforce Original = Spent + Remaining, and trying to enforce it would defeat the purpose of having three separate fields.
The opposite shape is also common:
- Original Estimate: 8h
- Time Spent: 12h
- Remaining: 0h
This is the ticket where you ran over but eventually finished. Original stayed at 8 because that’s what the original prediction was. Time Spent rolled up to the actuals. Remaining was reduced to zero when the work was done.
The thing to understand is that Original Estimate is the only one of the three that’s meant to be static. Time Spent and Remaining both move during the life of the ticket. If your sprint report is pulling Original, it’s measuring how good your team is at predicting work. If it’s pulling Remaining, it’s measuring how much capacity the sprint has left. Those are different questions.
What sprint reports actually use
Jira’s Sprint Burndown chart can be configured to use any of three measures: Story Points, Original Time Estimate, or Remaining Time Estimate. The default for new boards has been Story Points for several years now, on the assumption that most agile teams have decoupled estimation from clock hours.
If your board is configured on Remaining Estimate, the burndown line drops every time anyone logs work or manually reduces Remaining, and the chart reflects “is there work left to do” rather than “are we logging hours”. Velocity reports, Cumulative Flow, and the Sprint Report itself all pull from the same configuration choice. If your team is arguing about whether the burndown is “right”, the first question to ask is which field it’s reading.
Time tracking format
A small but easily missed detail: Jira parses time strings using a configured working day length, defaulting to 8 hours per day and 5 days per week. So 1d is 8h, and 1w is 40h. If your team works a 9-hour day, an admin has to change those values in the Time Tracking settings, or every worklog entered as 1d will be off by an hour. The legal m/h/d/w suffixes all combine; you can write 3h 30m and Jira understands.
This matters more than it sounds. Several Jira time tracking integrations send worklogs in seconds via the REST API (timeSpentSeconds), which sidesteps the format entirely. Others send the human string and rely on Jira to parse it. The first kind doesn’t care what your working day is set to. The second kind silently re-interprets 1d if you change the setting.
Story Points vs the time fields
Worth saying once: Story Points and the time fields are not the same thing, and they’re not meant to convert into each other. Story Points are a relative complexity measure attached to the issue, used during sprint planning. Time fields are hours, used during execution and reporting. Teams that try to maintain both rigorously usually end up dropping one. The pattern I see working is Story Points for planning and time fields for billing or compliance. Trying to use both for the same purpose tends to leave you with two numbers that don’t agree and no clear way to reconcile them.
Where third-party trackers fit in
The three native fields are usable on their own. You click Log Work on every issue you touch, fill in the time, choose a Remaining behaviour, save. The friction is real, which is why most teams reach for a separate tracker after a few sprints.
A good Jira time tracker should respect what the native fields are for, not paper over them. That means pushing worklogs that land on the right issue with the right Time Spent, giving you control over the Remaining behaviour on each entry, not silently overwriting worklogs you’ve edited inside Jira, and surfacing Original Estimate alongside the timer so you can see whether you’re already over budget.
The trackers that do this well treat the three fields as the source of truth. The trackers that don’t tend to maintain a parallel database of hours in their own cloud and push a stripped-down worklog string on a schedule, leaving Remaining Estimate to drift on its own. That second pattern is what people are seeing when they say “our Jira reports don’t match our timesheet”. They aren’t supposed to match. The timesheet is the tracker’s database. The Jira fields are something else entirely. I went deeper on the read-write side of this in two-way Jira worklog sync, if you want the engineering view.
A short reference
If you remember three things:
- Original Estimate is fixed at the start and meant to stay fixed. It answers “did we predict this right”.
- Time Spent is the rolling total of all worklog entries. It answers “how much has been spent”.
- Remaining Estimate is alive. It moves with each worklog by default, and you can override the behaviour on every entry. It answers “how much is left”.
The three don’t have to add up. The math is allowed to drift. The job of the fields is to answer three different questions, and arguments about them are usually arguments about which question your team actually wants the answer to.