How do I tell whether the team is actually working on the roadmap?

Roadmap Epics Touched counts how many of the epics marked CAPEX on the board had any task at all in the window, out of the total marked. An untouched epic had none — nothing was attributed to it, which is the direct answer to whether the committed roadmap is the roadmap being worked. Note the test is presence rather than progress: an epic counts as touched even if its only ticket never moved.

Why does the widget say there is no denominator?

The roadmap is whichever epics on the board are marked CAPEX — there is no separate flag or curated list. Until at least one is marked, the widget has no denominator, and it says so rather than showing 0 / 0, because "nobody has said which epics are the roadmap" is a different fact from "the team touched no roadmap".

How does an epic count as touched?

At least one task attributed to that epic was in the window. That is the whole test — no movement and no attention-day threshold, so an epic with one untouched ticket counts as touched. Attribution can be direct or inherited: the classifier walks the parent chain, so a task under a CAPEX-marked ancestor is attributed to it even when the task itself carries no classification.

How is this different from Board Elements Worked On?

This tile is the headline count. Board Elements Worked On shows the same epics individually, badged touched or untouched, and adds the figure this tile has no room for: how many tasks never appeared on the board at all.

Roadmap epic coverage: is the roadmap you committed to the one being worked?

Roadmap Epics Touched is the simplest question on the Team Focus view and the one most likely to embarrass a plan: of the epics that make up the roadmap, how many had a single ticket against them? Not enough progress — any ticket at all. It is a deliberately low bar, which is what makes a zero unarguable.

deckgauge · Board · Team Focus

9 / 14

roadmap epics received any work

5 received nothing at all

The tile, with what it is out of.

What it measures, and where the data comes from

The denominator is whichever epics on this board are marked CAPEX. There is no separate roadmap flag, no curated list and no schema marker — marking an epic CAPEX is an ordinary board edit, and that act is what declares it part of the roadmap.

The numerator is those epics with at least one task attributed to them in the window, across Jira and Azure DevOps. Note how weak that condition is: the task merely has to be in the window and attributed to the epic — it does not have to have moved, and it does not have to have accrued a single attention-day. An epic is "touched" on the strength of a ticket nobody worked, which is why this tile is read against Roadmap Focus rather than on its own.

No CAPEX epics means no answer, not zeroWith nothing marked, the widget replaces the number with an instruction: mark the epics that make up your roadmap as CAPEX on the board and they will appear here. Printing 0 / 0 would imply the team touched no roadmap, when the actual state is that nobody has said which epics are the roadmap. The two are not the same finding and must not look the same.

How the number is calculated

Attribution is the interesting half, because a task rarely carries the epic itself. The classifier walks the parent chain and attributes a task to the nearest ancestor that is a classified board row — so people classify the epic, not the forty tasks beneath it.

This matters more than it sounds. On the board that surfaced the behaviour, 27 classified epics covered 482 tasks while only 19 were being matched, because only the epics themselves carried the classification. Walking the chain is what closed that gap.

deckgauge · Every Task, and Why

Task	Classification reason	Attributed to
PLAT-118	Marked CAPEX on the board row.	PLAT-100
PLAT-141	Roadmap: inherited from PLAT-100, marked CAPEX on the board.	PLAT-100
BILL-22	Roadmap: inherited from BILL-2, marked CAPEX on the board.	BILL-2

How three tasks are attributed to two epics.

Given a board where PLAT-100, BILL-2 and three other epics are marked CAPEX, and only the first two received any of the window's work:

2 touched of 5 marked — the tile reads 2 / 5 with "3 received nothing at all" underneath. The tile is styled positively once more than half are touched, so at 2/5 it reads as a warning.

The row that decides is often not an epicThe classifier matches against board rows with no type filter, and most CAPEX rows on a real board are tasks, not epics. So the row that decides a task's class is routinely a Story, a Task or an Initiative. That is fine for the CLASS, but an epic attribution has to be an actual epic — a Story key in the coverage join would be a wrong answer rather than a vague one, so attribution falls back to the rule's or the model's epic instead of using whatever ancestor happened to decide.

How to read it

Read the untouched count first. It is the actionable half: an epic that received nothing across a whole window is either not really this quarter's roadmap, or it is being starved by work that is.

Then sanity-check the denominator. A number that looks too small usually means only part of the roadmap is marked CAPEX, and coverage is flattering itself by measuring against a subset. Fourteen epics when the roadmap has twenty-two is not 9/14 — it is an unknown fraction of twenty-two.

Read this against Roadmap Focus deliberately. High coverage with a low roadmap share of attention is a spread-thin signature: many epics touched a little, none advanced much. Low coverage with a high share is the opposite and usually healthier — the team is concentrating.

What it tells you over time

An epic that shows untouched for a second consecutive window has effectively been descoped without anyone saying so. That is the reading worth acting on, and it is why the widget counts "any work" rather than "enough work" — the binary is what makes two consecutive zeroes unambiguous.

Coverage that improves while the roadmap share of attention holds flat means the same effort is being spread across more epics. Whether that is good depends entirely on whether those epics need to finish in the same quarter.

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: the classification reason on each row names what decided its class — including “Roadmap: inherited from , marked CAPEX on the board”, which is how a task reaches an epic it does not itself carry. That reason is where a surprising attribution gets confirmed or corrected.

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 denominator that quietly flatters the number

deckgauge · Roadmap Epics Touched

6 / 7

roadmap epics received any work

1 received nothing at all

Good coverage of a partially-marked roadmap.

What you're seeing: 86% coverage looks excellent. The quarter's roadmap has 19 epics, and only 7 of them are marked CAPEX on the board. The widget is answering honestly about the set it was given; the set is wrong. Twelve roadmap epics are invisible to this number, and any of them could be untouched.

How to react: fix the input before reading the output. This is not a measurement bug — the widget cannot know which epics you meant, and it has no way to distinguish "not on the roadmap" from "on the roadmap but unmarked".

Managerial playMark the roadmap once, properly, and make it part of whatever ritual opens a quarter — this is a five-minute board edit that determines whether every roadmap figure on the view is trustworthy, and it is the single highest-leverage piece of data hygiene here. The incentive is worth stating to the team: the CAPEX field is cheap, someone usually maintains it for finance anyway, and filling it in beats having a model infer the same thing less defensibly. Once the full set is marked, expect coverage to drop — that is the number becoming true rather than getting worse, and it is worth saying so out loud before anyone reads the fall as a regression.

2. Broad coverage, no progress

deckgauge · Team Focus

Figure	Value
Roadmap epics touched	14 / 14
Roadmap share of attention	44%
Landed in production	11%
Never moved	28 / 91

Everything touched, nothing advanced.

What you're seeing: every epic on the roadmap got attention and almost nothing shipped. Coverage is perfect and meaningless. With 44% of attention on roadmap work and 11% of features landing, the team is working on the right things and finishing none of them — the classic result of committing to a full roadmap in parallel rather than in sequence.

How to react: perfect coverage is a warning here, not a success. Fourteen epics started and one in nine features shipped means the constraint is concurrency.

Managerial playSequence the roadmap instead of parallelising it, and be explicit that this is a change of plan rather than a change of pace: pick the three or four epics that must finish this quarter, and let the rest genuinely wait. Expect coverage to fall to something like 4/14 and treat that as the goal, which means telling whoever reads this dashboard what the new target is before they see the drop. Watch the landed-in-production figure as the real measure of whether it worked — if concurrency was the constraint, it should move within a window or two while coverage stays deliberately low.

Frequently asked

How do I tell whether the team is actually working on the roadmap?: Roadmap Epics Touched counts how many of the epics marked CAPEX on the board had any task at all in the window, out of the total marked. An untouched epic had none — nothing was attributed to it, which is the direct answer to whether the committed roadmap is the roadmap being worked. Note the test is presence rather than progress: an epic counts as touched even if its only ticket never moved.
Why does the widget say there is no denominator?: The roadmap is whichever epics on the board are marked CAPEX — there is no separate flag or curated list. Until at least one is marked, the widget has no denominator, and it says so rather than showing 0 / 0, because "nobody has said which epics are the roadmap" is a different fact from "the team touched no roadmap".
How does an epic count as touched?: At least one task attributed to that epic was in the window. That is the whole test — no movement and no attention-day threshold, so an epic with one untouched ticket counts as touched. Attribution can be direct or inherited: the classifier walks the parent chain, so a task under a CAPEX-marked ancestor is attributed to it even when the task itself carries no classification.
How is this different from Board Elements Worked On?: This tile is the headline count. Board Elements Worked On shows the same epics individually, badged touched or untouched, and adds the figure this tile has no room for: how many tasks never appeared on the board at all.

Related widgets

Board Elements Worked On — the same epics individually, plus work that never reached the board.
Roadmap Focus — how much attention the roadmap got, as opposed to how many epics it reached.
How Work Was Classified — how many tasks carry a CAPEX value at all.
Every Task, and Why — the attribution reason, row by row.
Method: Roadmap coverage and Classifying work.
Back to the widget reference.

Last updated 10 September 2026