How to Get Honest Worklogs in Jira Without Policing Your Team

Whenever I talk to an agency about computing real project margin, the same objection arrives within the first ten minutes, usually from whoever knows the delivery floor best: "our worklogs are rubbish." Hours logged in batches on Friday afternoon, generously rounded, dumped onto whichever ticket was nearest. If the inputs are fiction, the argument goes, the margin built on them will be fiction too.

The objection is half right. The data quality problem is real. Where it goes wrong is the assumed cause — carelessness — and therefore the assumed cure: pressure. I spent years on the delivery side of this and then years on the finance side of it, and the pattern is consistent: worklogs are exactly as honest as the system around them makes it cheap to be. People don't log fiction because they are lazy. They log fiction because the truth is expensive to record and the fiction is what gets rewarded.

So this is a how-to, but the method is not enforcement. It is removing, one by one, the reasons the truth isn't being told.

Step 1: decide what the worklogs are for — and say it out loud

Before touching any process, answer one question in writing: what are these hours used for? If the honest answer includes evaluating individuals — who is fast, who is slow, whose day looks thin — stop there, because no procedural fix survives that. People who know their logged hours feed their appraisal will log defensively, forever, and they will be right to.

The answer that produces honest data is: worklogs exist to cost projects, price future work, and protect the team from underscoped engagements. Not to measure people. Then make the commitment structural rather than rhetorical: no per-person hour leaderboards, no "who logged least this week", and margin visibility held at leadership level rather than pushed onto every screen — there are good reasons your PMs shouldn't see project margins, and this is one of them. The team can only believe the data isn't a stick if the stick is visibly absent.

Step 2: ask for less precision than you think you need

The classic timesheet asks for fifteen-minute increments across a fragmented day, which forces a choice between doing bookkeeping all day or inventing a plausible day at five o'clock. Nearly everyone sensibly picks the fiction — and once someone is inventing within the day, the whole log inherits the invention.

Here is the thing the finance side rarely says out loud: margin does not need minute-level data. A project's real margin moves on tens and hundreds of hours; whether Tuesday's ticket took 2.5 or 3 hours changes nothing that matters. Half-day resolution, honestly recorded, beats quarter-hour resolution performed. So ask for exactly that: which project(s) did today go to, roughly in halves. Precision you don't need is not rigour — it is the tax that makes people stop telling the truth.

Step 3: make logging happen where the work already is

Every context switch between "doing the work" and "recording the work" costs you data quality. If logging means opening a second tool, finding the right code in a dropdown of ninety, and reconstructing the day from memory, it will happen on Friday, in bulk, badly — and a financial stack that needs a companion time-tracking plugin to function has exactly this problem built in.

The team already lives in Jira, on tickets. Let the ticket be the timesheet: log on the issue you just worked, at the moment you move it, in the same two clicks. The practical side of setting this up — projects, issue types, a worklog convention that survives contact with a real team — is covered in configuring Jira for project profitability; the principle is simply that the shortest honest path must also be the easiest one.

Step 4: remove the incentives to game

This is the step most agencies skip, and it is the one that decides everything. Look at what your current numbers reward. If utilisation targets determine whether a team looks healthy, internal hours will migrate into billable codes — utilisation is the easiest agency number to manage upward, and it gets managed upward precisely where it is watched hardest. If estimates are graded pass/fail, hours will get shaved to fit them; the overrun doesn't disappear, it just relocates to whichever ticket has slack.

Every one of those distortions was purchased by a metric. Withdraw the metric and the distortion stops paying. Concretely: stop targeting individual utilisation, stop celebrating projects that "came in exactly on estimate" (real work never does — estimates are systematically off, and that's a pricing input, not a sin), and never, ever, make logged hours a proxy for effort in a performance conversation. You cannot ask for honest data while paying for flattering data. The system will always take the money.

Step 5: review gaps, not people

Some hygiene is still needed — the goal is honest data, not absent data. The trick is to aim the review at the dataset, not at the individuals in it. A ten-minute weekly pass, at team level, looking for three things:

• Unlogged days — whole days with nothing against them, usually a sign the workflow made logging awkward that day, occasionally a sign someone is drowning
• Orphan hours — time landing on catch-all tickets ("general", "misc"), which is honest logging with nowhere honest to put itself: a structure problem, not a person problem
• Sudden shape changes — a team whose logs abruptly flatten to uniform 8-hour blocks has started performing; something upstream started watching them, and step 4 needs re-checking

Raised as "the data has a gap here, what made logging hard this week?", these reviews improve the system. Raised as "you didn't log Thursday", they teach people to fill Thursdays with fiction. Same review, opposite outcomes.

Step 6: close the loop — show the team what the truth bought

Data quality is a relationship, and relationships run on reciprocity. If hours vanish into a finance process and nothing visible ever comes back, logging is a tax; taxes get minimised. So return the value where the team can see it: because the logs were honest, we could show this client the real cost of their change requests and get the next phase priced properly. Because the logs were honest, we stopped selling the kind of project that burned you out last winter. When the team watches their own data being used to defend them — against underpriced work, against scope generosity, against impossible deadlines — the logging stops being compliance and starts being self-interest. That, and not any reminder bot, is what sustains the habit through year two and beyond.

How good is good enough

A closing calibration, because perfectionism kills these initiatives as reliably as neglect: you do not need perfect logs. Margin computed on day-level, ±10%-honest data is a management-grade instrument; margin computed on performed data is noise at any resolution. Get the six steps roughly right and the worklogs become what they should have been all along — the quiet, boring, trustworthy foundation under every number the agency steers by.

It will not surprise you that this philosophy is built into Saldo: it reads the worklogs your team already makes, read-only, costs them at real employee cost, and shows margin to the people who price and plan — not as a surveillance feed, but as the financial layer on data your team was already producing. If you want to see whether your "rubbish" worklogs are already good enough to run real margin on — they usually are — the 15-minute demo answers that on your own Jira, and the numbers stay yours.

The shorter version: you don't get honest worklogs by watching harder. You get them by making the truth cheap to record, useless to game, and visibly worth telling.