How do you measure the percentage of time spent on roadmap work?

Roadmap Focus divides attention-days on roadmap-classified tasks by attention-days on all work that moved — unclassified included, not just the classified share — counting only tasks that actually changed state in the window. An attention-day is one calendar day a task sat in a working state — a proxy for where attention went, not a measure of effort.

Why does the percentage exclude parked tasks?

A task accrues attention-days whether or not anyone touched it. Counting parked tasks would raise the figure using days during which nothing happened, so tasks with no state change in the window are excluded from both the numerator and the denominator, and the widget prints how many days it dropped.

Why does the widget sometimes refuse to show a percentage?

When more than half the tasks in the window are unclassified there is no denominator worth dividing by, so it reports the unclassified count instead. Printing a confident 0% from a mostly-unclassified window would be a wrong answer that looks like a real one.

Is this the same as measuring engineering effort?

No. Tasks overlap — one engineer can hold a dozen in a working state at once — so attention-days across tasks routinely exceed the number of days in the window. It is a share-of-attention proxy and cannot be converted to FTE effort.

Roadmap vs unplanned work: what share of attention actually went to the roadmap

Roadmap Focus answers one question a VP of Engineering is asked every quarter and can rarely evidence: of the attention this team spent, how much went to the roadmap? It is a single percentage, and almost all of its value is in the qualifier printed underneath it.

deckgauge · Board · Team Focus

38%

of attention went to roadmap work

73 of 190 attention-days · moved tasks only · 84 parked days excluded · 1 unclassified

The tile, with the qualifier that travels with the number.

What it measures, and where the data comes from

The population is every task the synced source returned for the window — Jira and Azure DevOps — after de-duplication. Each task carries a class:

A — Roadmap / CAPEX. Work that advances the roadmap.
B — OPEX. Business-as-usual: defects, support, keeping the lights on.
C — Internal technical. Refactoring, tooling, infrastructure.
Unclassified. No classifier could reach it. This is a fact about the pipeline, not a judgement about the work — and it is deliberately not something the model is allowed to answer.

Each task also carries an attention-day count: calendar days it spent in a state this board treats as working, clipped to the window. The percentage is the class-A share of those days.

How the number is calculated

Take a six-task window — five that moved and one that did not. The Moves column is real state changes inside the window — a bulk-migration burst is excluded, so an import that rewrites changelog entries at one instant cannot make a year-old task look active.

deckgauge · Every Task, and Why

Task	Class	Attention-days	Moves	Counted?
PLAT-118	A — Roadmap	40	6	yes
PLAT-204	A — Roadmap	33	2	yes
SUP-991	B — OPEX	60	9	yes
INF-77	C — Internal	30	3	yes
OPS-12	? — Unclassified	27	4	yes — see below
PLAT-31	A — Roadmap	84	0	no — parked

The rows behind one percentage.

Five tasks moved. Their attention-days total 40 + 33 + 60 + 30 + 27 = 190, of which class A contributes 40 + 33 = 73.

73 ÷ 190 = 38.4%, printed as 38%, with 73 of 190 attention-days · moved tasks only · 84 parked days excluded · 1 unclassified underneath.

The last segment counts tasks, not daysRead that qualifier carefully: 73 of 190 attention-days and 84 parked days are DAY counts, but 1 unclassified is a TASK count — one ticket, which happens to carry 27 of the 190 days. The tile switches units in its last segment, and nothing on its face says so. The mistake to avoid is reading that figure as days and concluding the unclassified share is tiny. It is one ticket of the six in this window, and it carries 27 of the 190 days the percentage divides by — 14% of the denominator, which is not tiny at all. (Note that the unclassified count and the task total behind it span every task in the window, parked ones included, while the day figures beside them cover only the five that moved. Three of the four segments are over one population and the last is over another.)

Unclassified days are in the denominatorOPS-12 is the row to notice. Nothing could classify it, and its 27 days still count toward the total the percentage divides by — the denominator is all work that moved, not the classified share of it. Dropping it would raise the figure to 73 ÷ 163 = 45%, and that is not a rounding difference: it is the number claiming the team spent 45% of its attention on the roadmap when 14% of the attention it is dividing by was work nobody has categorised. This has been got wrong once in the product itself — a three-term total printed "14% of attention went to roadmap" directly above the caveat "133 of 779 attention-days", and 133 ÷ 779 is 17%, so the headline contradicted its own qualifier.

Then note what PLAT-31 does. It is the largest single block of attention-days in the window, it is roadmap work, and it is excluded — because nothing happened to it. Had it been counted, the headline would have read 157 ÷ 274 = 57%, and that 57% would have leaned almost entirely on a ticket nobody touched.

A parked task still accrues daysThis is deliberate, not a bug. A task earns attention-days for sitting in a working state whether or not anyone works on it, because the parked-versus-moved distinction has to be made after both numbers exist. Roadmap Focus resolves it by excluding parked days and saying so. The Focus Map resolves it the other way — it draws parked days as hatched squares, which is the only place on the view where a large amount of nothing-happening is visible.

How to read it

Read the qualifier before the percentage. It names the numerator, the denominator, the parked days dropped and the unclassified count, and any one of those can change what the number means. A 38% on 190 days is a finding; a 38% on 9 days is noise.

Then check the parked-day exclusion against the percentage itself. A modest roadmap share sitting next to a large parked exclusion is the signature this widget exists to catch: attention went somewhere, and it was not roadmap work that progressed.

There is no benchmark tier here, and that is intentional. The right roadmap share for a platform team carrying a support rota is not the right share for a team shipping a new product, and a threshold would invite gaming the classification rather than changing the work.

What it tells you over time

The trend is worth far more than any single reading, because the classification improves as people mark up the board. A share that climbs while the unclassified count falls is mostly a measurement improving, not the work changing — check How Work Was Classified before claiming the second.

The reading to act on is a roadmap share falling across two or three windows while the total attention-days hold steady. That is unplanned work displacing planned work at constant capacity, which is a prioritisation problem rather than a staffing one.

Check the raw data Every number here is reproducible. Add Every Task, and Why — the ledger — to the same board and the same period. It lists every task with its raw state from Jira or Azure DevOps sitting beside the delivery stage it was mapped to, its class, the reason the classifier gave, its owner, its source system and its move count, and it filters by person, class and stage.

For this widget: set the Class filter to A · Roadmap / CAPEX to see exactly which tasks fed the numerator, then read the Moves column — every row showing 0 is one of the parked tasks excluded from both halves of the fraction.

The raw state sits next to the mapped stage deliberately: that is what lets you see how a state was interpreted and argue with it, rather than being handed a stage and asked to trust it. See the ledger reference for the full column list, or Ledger & caveats for the method behind it.

Example situations

1. A confident-looking percentage built on almost nothing

deckgauge · Roadmap Focus

71%

of attention went to roadmap work

12 of 17 attention-days · moved tasks only · 240 parked days excluded

A high share over a tiny denominator.

What you're seeing: 71% reads like a well-focused quarter. The denominator is 17 attention-days, and 240 days were dropped as parked. Almost nothing moved in this window; of the little that did, most was roadmap work. The percentage is arithmetically correct and tells you nothing about focus — it tells you the board is stalled.

How to react: ignore the percentage entirely and go to Never Moved and the Focus Map. A 240-day parked exclusion is the actual headline here, and this tile is the wrong widget to read it from.

Managerial playDo not report this number upward — it will be quoted back at you as evidence of focus and it cannot survive a follow-up question. Treat the parked exclusion as the finding instead: pull the parked roadmap tasks out of the ledger, and for each one establish whether it is blocked, abandoned, or simply forgotten. Close what is abandoned before the next planning round, because a backlog that holds 240 days of untouched roadmap work will produce this same misleading tile every window until someone prunes it.

2. Roadmap share sliding while capacity is unchanged

deckgauge · Roadmap Focus — three consecutive windows

Window	Roadmap share	Total attention-days	Unclassified
Q1	52%	318	8
Q2	41%	324	7
Q3	29%	311	9

Total attention flat, roadmap share falling.

What you're seeing: the team is spending the same attention it always did, the classification quality has not moved, and the roadmap share has fallen 23 points. Unplanned work is displacing planned work at constant capacity. Because the unclassified count is stable, this is not a measurement artefact.

How to react: resist the reflex to ask for more roadmap commitment next quarter. Capacity is not the constraint — allocation is, and the allocation is being decided by whatever is generating the class-B work rather than by the plan.

Managerial playFind out what the OPEX work actually is before you try to reduce it: split the class-B population in the ledger by owner and by epic, because "unplanned work" is usually two or three recurring sources rather than a diffuse tax. Then make the trade explicit rather than implicit — take the measured share to whoever owns the roadmap and agree either that the support load is genuinely the priority, in which case the roadmap commitment should shrink to match, or that it is not, in which case someone has to own reducing it. The failure mode to avoid is leaving the ratio undiscussed and asking the team to absorb both, which is how this chart reaches 29% and keeps going.

Frequently asked

How do you measure the percentage of time spent on roadmap work?: Roadmap Focus divides attention-days on roadmap-classified tasks by attention-days on all work that moved — unclassified included, not just the classified share — counting only tasks that actually changed state in the window. An attention-day is one calendar day a task sat in a working state — a proxy for where attention went, not a measure of effort.
Why does the percentage exclude parked tasks?: A task accrues attention-days whether or not anyone touched it. Counting parked tasks would raise the figure using days during which nothing happened, so tasks with no state change in the window are excluded from both the numerator and the denominator, and the widget prints how many days it dropped.
Why does the widget sometimes refuse to show a percentage?: When more than half the tasks in the window are unclassified there is no denominator worth dividing by, so it reports the unclassified count instead. Printing a confident 0% from a mostly-unclassified window would be a wrong answer that looks like a real one.
Is this the same as measuring engineering effort?: No. Tasks overlap — one engineer can hold a dozen in a working state at once — so attention-days across tasks routinely exceed the number of days in the window. It is a share-of-attention proxy and cannot be converted to FTE effort.

Related widgets

Where the Attention Went — the same attention-days, broken down per person rather than summed into one share.
How Work Was Classified — who or what decided each task's class, which is what this percentage rests on.
Never Moved — the tasks excluded here as parked, counted directly.
Every Task, and Why — the rows behind the number.
Method: Classifying work and Attention days.
Back to the widget reference.

Last updated 10 September 2026