Jira Log Work: Getting Hours In Without Derailing the Sprint

Somebody needs hours. It might be a client invoice, a capitalisation split, or a manager who wants to know why a two point story took a week. Jira has a Log work action, the team has been told to use it, and the numbers that come out the other end are somewhere between incomplete and misleading. Time entries cluster on Friday afternoon. Two people record the same pairing session. One developer logs 1d and means a full day, another logs 1d and means twenty four hours of elapsed clock.

None of that is a discipline problem. It is a configuration problem and a habit problem, in that order, and both are fixable without buying anything. What is not fixable without buying something is the part most teams actually want, which is a weekly timesheet somebody signs off.

Log work is three numbers, and the third one causes the arguments

Time tracking on a work item is not a single field. It holds an original estimate, the time spent so far, and a remaining estimate. Logging work writes to the second and, depending on a choice made in the dialog, rewrites the third.

The Log work dialog itself is small. It takes the time spent, the date started, a choice about the remaining estimate, and an optional work description. That choice is where teams quietly break their own reporting, because it offers three behaviours: automatically adjust the remaining time, set a new remaining estimate, or do nothing.

Automatic adjustment subtracts what was logged from what was left. It is the right default for work that was estimated accurately, and it is actively harmful for work that was not, because a task estimated at two hours that has already taken six will show zero remaining while the work continues. Setting a new remaining estimate is the honest option and the one nobody picks, because it requires admitting in public that the estimate was wrong. Doing nothing leaves the remaining estimate frozen, which is fine for billing and useless for any burndown.

The consequence is worth stating plainly. A team that logs hours for invoicing and a team that logs hours for forecasting need opposite settings in the same dialog, and if nobody says which one applies, individuals will choose differently and the report will average two incompatible meanings.

Before anything: making the field appear

A surprising share of searches for this end at a work item with no time tracking section on it at all.

Two things have to be true. Time tracking has to be enabled, which is an app admin setting, and the person logging has to hold the right permission, documented as Browse spaces and Work on work items. Atlassian's guidance when the field is missing is unambiguous: contact the Jira admin. Time tracking is on by default, and the documentation notes that disabling or re-enabling it does not lose existing data, which makes it safe to toggle while testing.

The field can also be hidden without the feature being off. In company-managed spaces the Time Tracking field lives in a field configuration, and in team-managed spaces it is controlled by customising the work item fields. So the field being absent in one project and present in another is normal and says nothing about the site-wide setting.

One more constraint catches large hierarchies: when a work item has more than 100 child items, those children cannot be included in time tracking. Teams that model an initiative as one parent with hundreds of children discover this only when the rollup stops matching.

There is also a wrinkle specific to free sites. On the Free plan, space permissions, roles and work-level security are not customisable, and on a site that has always been Free, everyone with access is an admin for all spaces. That removes the permission question entirely, but it also means there is no way to restrict who can edit or delete a logged entry, which matters the moment the hours are attached to money.

The settings that decide whether the totals mean anything

Four admin settings determine how every entry is interpreted. They are configured once, usually by someone who is not the person reading the reports.

Working hours per day and working days per week convert between units. This is the source of the most common disagreement about Jira hours. When a developer types 1d, Jira does not store a day. It stores however many hours the site says a day contains, and decimals are accepted, so a site configured for 7.5 will convert differently from one configured for 8. Nothing in the dialog tells the person typing which it is.

Default unit decides what a bare number means. Minute, hour, day or week. If it is set to minute and somebody types 4 intending four hours, the entry is four minutes, and it will pass unnoticed because a work item with a few minutes logged looks like a work item nobody has touched.

Time display format offers Pretty, Days or Hours. This changes only the presentation, but it changes which errors are visible. In Pretty format, a long run of small mistakes reads as a tidy list of short durations. In Hours format, the same data makes an implausible total obvious at a glance.

The fourth setting is subtler. Copying of comments to work description takes the comment written during a workflow transition and copies it into the work description field on the entry. Switched on, a team that comments as it moves cards gets a populated audit trail for free. Switched off, the description is blank unless each person fills it in during the dialog, and a year later nobody can explain what a four hour entry covered.

Entries accept weeks, days, hours and minutes as w, d, h and m, and combinations work, so 2d 4h 30m is valid and so is 3w. Teaching the team to always include a unit costs one message in a channel and removes a whole class of silent error.

Friday reconstruction is the real accuracy problem

Assume the configuration is perfect. The hours will still be wrong, because of when they are entered rather than how.

Work logged at the moment the work stops is a recollection of minutes. Work logged on Friday for the week is a reconstruction from calendar entries, chat history and the branch log, and reconstruction rounds. It rounds to the hour, it rounds toward the estimate, and it quietly drops the twenty minute interruptions that make up a surprising fraction of a week. The totals still add to forty because people balance them to a plausible number, which is exactly why timesheets assembled on Friday look neater than ones assembled daily and describe reality less well.

Two mechanical changes move the needle more than any policy about diligence. The first is reducing the number of clicks between finishing a piece of work and recording it, which usually means logging from wherever the status is already being changed rather than opening a separate dialog. The second is making the week visible to the person filling it in. A list of entries scattered across work items gives nobody a sense of whether Tuesday is accounted for, whereas a grid of days against tasks makes a missing afternoon obvious without anyone being chased.

Jira's native model is per work item by design. Getting a per person week out of it means building a report or a filter, and that report is a read-only view rather than a place to type. This is the gap that the entire Marketplace category exists to fill.

What Jira does not do natively, and what filling the gap costs

The native feature records durations against work items. It does not run a timesheet process. Specifically, there is no period to submit, nobody to approve it, no billable and non-billable split, and no structured field for which client or contract an entry belongs to.

Timesheet apps for Jira add exactly those pieces. Tempo, the most established of them, describes the cycle the way finance teams expect it: people log time within a reporting period and then submit the timesheet at the end of that period to be reviewed and approved, usually by a team lead or manager, with project level sign-offs available as well. It also adds worklog attributes, meaning extra fields on the log time form as dropdowns, lists or checkboxes, with the captured context flowing into reports, plus billable against non-billable hours and a capital against operating expenditure split.

That is the shape of the requirement, whoever supplies it. The choice is about where the hours are typed and what the addition costs per person.

Route	Where hours are entered	Per person weekly view	Submission and approval	Added cost
Jira log work alone	The dialog on each work item	Only by building a report	None	Included
Jira plus a timesheet app	The item, or a weekly grid	Yes	Yes, with periods and sign-off	Per user, on top of Jira
A standalone time tracker	Inside the tracker, linked loosely	Yes	Depends on the tier, for example Clockify puts time approval on its Standard plan at 6.99 US dollars per user monthly or 5.49 paid annually, above a free plan capped at five users	Per user, plus reconciliation work
A task tool with timesheets built in	On the card being worked	Yes	Yes	Per user add-on where offered

The reconciliation work in the third row is easy to underestimate. Two systems holding the same hours means two sources of truth, a mapping between project names, and a person whose job it is to explain the difference at month end.

Deciding which problem is being solved

The decision follows from who reads the numbers, not from which tool has more features.

If the hours exist to inform the team's own forecasting, Jira alone is enough, and the work is configuration and habit: fix the hours per day, set the default unit, agree what the remaining estimate choice means, and log at the point of work. Nothing needs to be bought.

If the hours leave the team, for an invoice, a grant report, or a capitalisation schedule, then an approval step is not optional and neither is a record of who approved what. That is a purchase, either an app on top of Jira or a tool that includes the period and the sign-off. Teams already paying per seat for Jira should price the add-on per seat before assuming the incremental route is the cheaper one, because a board tool that bundles the boards and the timesheet often lands close to the combined per seat total of the pieces.

There is a third case that gets missed. Some teams are tracking hours because a client contract mentions them, on work that is otherwise managed on a board, and nobody actually wants Jira's estimate model at all. For that shape, tools built around a card with a timesheet attached to the same set of boards remove the estimate arithmetic entirely, and the difference in how a Jira style issue tracker and a board tool model the same project is worth reading before committing to either.

What to change first

Open the time tracking settings and read the hours per day, days per week and default unit values out loud to the team, because at least one of them will surprise somebody. Then pick a single meaning for the remaining estimate choice and write it in the channel where the team actually reads things. Those two steps cost an hour and remove most of the ambiguity in the data. Only after that is it worth deciding whether the missing piece is approval, in which case the choice is an app on top of Jira or a tool where the timesheet sits on the same cards as the work.

Q1. Why is there no Log work option on the work item?

Either time tracking is not enabled for the site, which is an app admin setting, or the person looking does not hold the required permissions, documented as Browse spaces and Work on work items. The field can also be hidden per project, through the field configuration in a company-managed space or by customising work item fields in a team-managed one, so its absence in one project says nothing about the rest of the site.

Q2. Does 1d mean eight hours in Jira?

It means whatever the site's working hours per day setting says, and that value is configurable, including as a decimal. A site set to 7.5 will convert 1d to seven and a half hours. Nothing in the log work dialog displays the conversion, which is why teams that log in days and read reports in hours often disagree about totals until somebody checks the setting.

Q3. What is the difference between the three remaining estimate options?

Automatically adjusting subtracts the logged time from the remaining estimate, which is correct only when the original estimate was accurate. Setting a new remaining estimate replaces the number with a current judgement, which is the honest option for work that has overrun. Doing nothing freezes the remaining estimate, which suits billing but leaves burndown charts describing a plan that no longer exists.

Q4. Can Jira produce a timesheet that a manager approves?

Not on its own. The native feature records durations against work items and has no reporting period, no submission step and no approver. Marketplace apps add that cycle, with people logging time inside a period and submitting it for review and approval by a team lead or manager, plus billable and non-billable splits and extra fields on the logging form.

Q5. Is a separate time tracking tool simpler than adding an app to Jira?

It is simpler to buy and harder to live with. A standalone tracker gives a clean weekly grid and often a free tier for a very small team, but the hours then live outside the work items, project names have to be mapped between the two systems, and somebody has to explain the discrepancy at month end. Keeping the hours attached to the task they belong to avoids that reconciliation entirely.