Attention days: measuring focus without timesheets
Every percentage on the Team Focus tab divides by attention days: calendar days a task spent in a working state, inside the window. It is derived entirely from transition history your tracker writes anyway — nobody fills anything in — and it is labelled a proxy on the face of the widget rather than in a footnote.
What counts as an attention day
A task enters a working state, and every calendar day it sits there is an attention day, clipped to the reporting window. The defaults:
| System | Working states |
|---|---|
| Jira | In Progress, Code Review |
| Azure DevOps | In Progress, Pull Request Doing, Send Back to Dev |
What it is good for is a denominator: of everything this team was holding open, what share of it was roadmap work? That question does not need hours, and it is the question a quarterly review actually asks.
Moved versus parked
A task accrues attention days whether or not anyone touched it. A ticket that entered In Progress in March and is still there in June has ninety-odd attention days and possibly no work behind them.
So the headline split counts only tasks with at least one real state change in the window, and parked days are reported separately. On the reference window that is the difference between a 17 / 31 / 52 split across the three classes and a 20 / 37 / 44 one — and the gap is almost entirely three of the team lead's tickets sitting 89 days in a working state without moving.
A parked cell in the Focus map is a distinct visual state, not a hidden exclusion. You can see which work is parked rather than having it quietly disappear from a percentage.
Never Moved
The Never Moved tile counts tasks with zero state changes in the window — 31 of 105 on the reference window. It is the cheapest signal on the tab and usually the most actionable: a third of the open work was not touched at all, which is a planning conversation rather than a performance one.
Note that the tile's denominator is every task, including cancelled ones. Those tasks are in its numerator too, so shrinking only the denominator would inflate the percentage past what the data supports.
Where the Attention Went
A stacked bar per person, split by class, with every segment directly labelled rather than relying on colour alone.
Attention days per person, split roadmap / OpEx / internal.
Read this for shape, not for ranking. A person whose bar is mostly OpEx is not underperforming — they are, quite likely, the person absorbing the interrupts so everyone else's bar can be roadmap work. That pattern is exactly what the chart is for.
Person by Person
The scorecard carries one row per team member: Tasks, Never moved, In prod, Unshipped, Working days and the Attention split.
It ends with a line that is not a disclaimer but a correction to how the table will otherwise be read:
Active working days, and the peer baseline
Working days counts distinct weekdays with at least one non-merge commit, over the weekdays in the window or the member's own record, whichever is later. Merge commits are excluded because they measure a Git workflow, not a day's work.
Commit counts are reported against the median commits per developer across the organisation over the same window. Without a peer baseline a commit count means nothing at all — teams and codebases differ far too much for an absolute number to carry information.
The late-joiner floor
Before any percentage is computed, each member's first recorded activity is found across commits, work items and transitions. If it falls inside the window, every rate for that person runs against their own record from that date and carries a marker in the caveats.
Someone with no recorded activity at all is deliberately not treated as a late joiner. There is nothing to measure, and inferring a start date from silence is the same mistake in another form.
What is deliberately not measured
Two things you might expect and will not find:
- Lines changed and pull-request size. Azure DevOps reports zero additions and deletions on essentially all pull requests, and its commit change counts are file counts rather than line counts. Any metric built on that would be wrong, so both are omitted rather than estimated — and the caveats widget says so on every render.
- Hours. Deckgauge has a timesheet that derives time in status, and it is a different tool for a different question. Focus is about proportion, not duration.
If you want per-engineer PR size and review load, those live on the Engineering Intelligence tab, where GitHub and GitLab supply the line counts Azure DevOps does not.
If it looks wrong
| Symptom | Cause | Fix |
|---|---|---|
| One person's attention days exceed the days in the window | They held several tasks in a working state at once | Expected — attention days are a share proxy, not effort |
| Everyone's days look inflated after a migration | No migration cutoff is set for this board | Set one so import changelog entries stop counting as work |
| A person shows a very low rate | They may have joined mid-window | Check the caveats for a late-joiner entry naming them |
| A manager's row looks weak | Reviews, mentoring and incident work are not in these columns | Read their review counts on the Intelligence tab instead |
| Attention days are all zero | The board's working states are not in your tracker's vocabulary | Check the stage map — it lists what your sources actually report |
Frequently asked
- What is an attention day?
- A calendar day a task spent in a working state, counted inside the reporting window. Working states default to In Progress and Code Review on Jira, and In Progress, Pull Request Doing and Send Back to Dev on Azure DevOps. It is a share-of-attention proxy, not effort: tasks overlap, so one person’s days summed across their tasks can exceed the number of days in the window.
- Why not just measure hours spent per ticket?
- Because almost nobody records them accurately, and a metric that depends on manual entry decays the moment people are busy. Attention days are derived from transition history the tracker writes anyway, so they cost nothing to collect and cannot be forgotten. The trade-off is stated on the widget: they describe share of attention, not hours worked.
- What does "parked" mean on the Focus map?
- A task accrues attention days whether or not anyone touched it, so a ticket left in progress for three months keeps accumulating. Parked means exactly that: days accrued with no real state change in the window. The headline split counts only tasks that actually moved, and parked days are reported separately rather than folded in silently.
- How does Deckgauge avoid penalising someone who joined mid-quarter?
- Before any percentage is computed, it finds each person’s first recorded activity across commits, work items and transitions. If that falls inside the window, every rate for that person is computed against their own record from that date and the figure is marked. On the reference window this took one engineer from an apparent 38% active days to a true 75%.
- Why does the per-person table warn about low counts?
- Because it counts tickets only. Reviewing, mentoring, incident response and meetings appear in none of its columns. On the reference window the team lead showed 16 tasks and 0 in production while opening more pull requests and casting more reviews than anyone he managed — a low row is evidence of nothing on its own.
Related
- Team Focus — the view these figures sit on.
- Delivery stages — where the attention ended up.
- Classifying work — what the three coloured segments mean.
- Workload — the per-engineer view built on time in status.
- Ranking — the separate, explicitly opt-in per-engineer comparison.
Last updated