The working practices these numbers depend on

Nobody logs time in Deckgauge — hours are derived from how long each issue sat in an in-progress status. That makes the tracker's discipline the data. A ticket left parked in In Progress doesn't only look stale on a board; it keeps accruing hours, inflating that person's timesheet, workload row, and WIP count for as long as it sits there.

One parked ticket inflating a single row.

Why the tracker's discipline is the data

The engine only sees status transitions — it has no record of "what I actually did today." A ticket sitting in an in-progress status for three weeks because it was forgotten looks identical to three weeks of real work: it counts the full span, subject only to the daily cap. The fix isn't a smarter engine, it's cleaner status hygiene.

The practices

1. One active task per person — spreading attention across several simultaneously in-progress tickets doesn't multiply real hours, but it does split the credited time thinner and murkier across all of them.
2. Move parked work out of the active set — if something is blocked or paused, move it to Blocked (or any status outside the active set), rather than leaving it sitting in In Progress. That's the correct way to pause the clock.
3. Close at merge — the longer an issue lingers after the code is in, the more accrued time it silently picks up.
4. Don't skip states — jumping straight from In Progress to Done, past an intermediate Code Review or QA status your team normally uses, produces no span for the skipped state, quietly erasing that stage's time rather than crediting it elsewhere.
5. Keep status names consistent across projects — the default in-progress test is name-based (see what counts as in-progress), so "QA Ready" on one board and "Ready for QA Analysis" on another are treated differently even if they mean the same thing.
6. Keep assignees set — per-person numbers only exist because a span's assignee resolves to an employee identity. An unset or unmatched assignee lands in the timesheet's Unmatched row instead of anyone's total.
7. Link PRs to tickets — the report's epic and classification rollups depend on tracing an issue back to its initiative; an orphaned PR can't be attributed.

The guardrails, and their limits

Two mechanisms cap the damage from imperfect status hygiene — neither fixes the underlying process:

• The per-tree daily hours cap (/settings/timesheet-statuses?tree=…, default 8h) bounds how much time one engineer can accrue in a single day, so a ticket left open overnight or over a weekend can't inflate one day past a realistic capacity. It caps the day's total — it has no view on whether the ticket should have closed weeks ago.
• Retired-project clipping — when a Jira project stops syncing, its issues' spans are clipped to the retirement cutoff instead of accruing indefinitely against a source that no longer updates. Without marking a project retired, its last-open tickets look like they're still being worked forever.

If it looks wrong

Related

• Choosing what counts as in-progress — the settings these practices are guarding.
• Per-engineer workload — where a parked ticket first becomes visible.
• Connecting sources — marking a project retired lives under Sources.

Last updated 17 August 2026