Work that never reached the board: measuring the gap between the two

Every roadmap epic on this board, badged touched or untouched — and underneath, the finding the whole Team Focus view exists to make possible: how much of the work never appeared on this board at all.

deckgauge · Board · Team Focus
EpicStatusTasks
PLAT-100touched31
BILL-2touched12
ONB-14touched4
SEC-9no activity0
MIG-3no activity0

Epics badged, with the off-board gap called out.

38 of 122 tasks never appeared on this board. They exist only in the synced source. This view reads that source, not the board rows, so the gap is visible rather than invisible.

What it measures, and where the data comes from

Two things, and the second is the reason to add the widget:

  • Epic coverage. Every epic marked CAPEX on this board, badged green when at least one task attributed to it was in the window and red when none was, with the task count on hover. The condition is presence, not progress — a task attributed to the epic need not have moved or accrued any attention for the epic to badge green.
  • The off-board count. How many of the window's tasks never appeared on this board at all.
This view reads the source, not the boardThat is the architectural decision the off-board number depends on. Every other board-scoped metric in the product measures the rows on the board. This view queries what Jira and Azure DevOps actually returned for the window, so work that was never added to the board is present in the data and can be counted. A board-scoped query cannot report its own gaps — the tasks it is missing are, by construction, not in it.

How the number is calculated

Each task the source returned carries a flag for whether a corresponding board row exists. The off-board count is the tasks where it does not.

deckgauge · Every Task, and Why
TaskSourceOn this board?Counted in…
PLAT-118Jirayesepic coverage + totals
PLAT-141Jirayesepic coverage + totals
SUP-991Jiranooff-board count + totals
OPS-40Azure DevOpsnooff-board count + totals

On-board and off-board tasks in one population.

Two of four tasks never reached the board, so the widget reports 2 of 4 tasks never appeared on this board. Note that off-board tasks still count in the window's totals and in the attention figures — they are real work, and excluding them would reproduce exactly the blindness the widget is built to expose.

Epic attribution follows the same parent-chain walk used elsewhere: the classifier attributes a task to the nearest ancestor that is a classified board row, so an epic can be badged touched on the strength of work recorded against a sub-task several levels down. See Roadmap Epics Touched for the worked attribution example.

How to read it

Read the off-board count first, and read it as a statement about your other metrics rather than about the team. Thirty-eight of 122 tasks off-board means roughly a third of the work is invisible to every board-scoped widget in the product — so any velocity, WIP or completion figure taken from this board is a figure about two thirds of reality.

Then read the red badges. An epic with no task at all across a whole window is either not really this quarter's roadmap or is being starved. Read a green badge as the weaker claim it is: something was attributed to that epic, not that anyone advanced it.

If no epics are listed at all, that is the finding: nobody has marked which epics constitute the roadmap, and until someone does, coverage has no denominator.

What it tells you over time

A rising off-board count is usually a process drifting rather than a team misbehaving — a new intake channel that bypasses the board, a support queue that was never integrated, or an adjacent team's tickets landing in the same project. It is worth diagnosing by where the off-board tasks come from rather than by how many there are.

The same epic showing red for two consecutive windows has effectively been descoped without a decision, which is the reading to escalate.

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 ledger lists every task the source returned, on-board or not, so the off-board population is inspectable rather than a bare count. Look at the System column while you are there — a task tracked in both Jira and Azure DevOps shows as Jira + Azure DevOps, because it was merged on a normalised title.

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 third of the work is not on the board

deckgauge · Board Elements Worked On
FigureValue
Epics touched9 / 11
Tasks in window122
Never appeared on this board38 (31%)

Coverage looks fine; the count underneath does not.

What you're seeing: epic coverage is strong, and 31% of the work never reached the board. The roadmap is being worked and tracked; something else — very likely support or interrupt work — is being worked and not tracked. Every board-scoped metric you have been reporting is about the other 69%.

How to react: find out what the 38 tasks have in common before doing anything about the board. This is almost always one or two identifiable channels, not 38 individual oversights.

Managerial playPull the off-board tasks from the ledger and group them by project key and owner — the pattern usually names itself immediately, and it is typically a support queue, an adjacent team's project, or an intake route that predates the board. Then make a deliberate choice rather than a default one: either bring that channel onto the board so your metrics cover the real work, or accept it is out of scope and stop quoting board-scoped numbers as team-wide ones. The failure mode to avoid is asking the team to "use the board properly", which treats a routing problem as a discipline problem and will not survive the next busy week.

2. Two epics red for the second window running

deckgauge · Board Elements Worked On
EpicQ2Q3
PLAT-100touchedtouched
BILL-2touchedtouched
SEC-9no activityno activity
MIG-3no activityno activity

The same two epics, two windows apart.

What you're seeing: two epics have received no work at all for six months while remaining on the roadmap. Nobody decided to drop them; they have simply lost every prioritisation contest without the loss ever being recorded as a decision.

How to react: the widget counts "any work" rather than "enough work" precisely so that two consecutive zeroes are unambiguous. This is not a resourcing question yet — it is a question about whether these are still commitments.

Managerial playTake both epics to whoever owns the roadmap and force the decision: either they are commitments, in which case something currently being worked has to give way, or they are not, in which case unmark them and let the coverage figure tell the truth. A security or migration epic sitting untouched for two quarters is the shape that later becomes an incident or an urgent forced march, so the value here is in surfacing it while it is still a scheduling conversation. Whatever is decided, record it — an epic quietly carried for a third quarter is the same failure repeating.

Frequently asked

Why does my board not reflect the work the team actually did?
Board Elements Worked On measures exactly that gap. It reads the synced source rather than the board rows, so tasks that exist in Jira or Azure DevOps but never appeared on this board are counted and reported instead of being silently absent.
What does the off-board count mean?
How many of the window’s tasks never appeared on this board at all. They exist only in the synced source. A large count means every board-scoped metric elsewhere is measuring a subset of the real work.
How is this different from Roadmap Epics Touched?
Roadmap Epics Touched is the headline count — how many of the marked epics got any work. This widget shows the same epics individually, badged touched or untouched, and adds the off-board figure the tile has no room for.
Why are no epics listed?
Because no epic on the board is marked CAPEX, and marking epics CAPEX is what declares them the roadmap. Until at least one is marked there is nothing to badge, and the widget asks you to mark them rather than reporting an empty roadmap.

Related widgets

Last updated