Roadmap coverage: which epics received nothing
Three Team Focus widgets answer the coverage question from both ends: what did the roadmap receive, and what did the board miss. The second is usually the more uncomfortable of the two.
Where the roadmap epic set comes from
There is no list to curate. A board row is a roadmap epic when it is both:
- marked CapEx in the board's CapEx/OpEx column, and
- typed Epic in the source tracker.
Both halves are load-bearing. Drop the CapEx half and an OpEx or unclassified epic joins a set whose entire meaning is "the roadmap". Drop the epic half and — on a real board, where most CapEx rows are tasks — the denominator fills up with things that are not epics at all.
The set is also deliberately not derived from what the window's tasks reference. An epic that nothing points at would vanish, and that would delete the one figure these widgets exist to report: N epics received nothing at all. The denominator has to be independent of whether work happened.
Turning the coverage widgets on
If Roadmap Epics Touched reads 0 of 0, nothing on the board satisfies the predicate. The fix is one pass over your epics:
- Open the board and make sure the CapEx/OpEx column is visible — add it from the columns panel if not.
- Select your roadmap epics. Multi-select works, and a bulk change is a single request.
- Set them to CapEx.
That one action does two things at once: it populates the coverage denominator, and — through classification inheritance — it classifies every task hanging beneath those epics as roadmap work, with no model call at all.
Epic are admitted. ADO's Agile and Scrum templates also place Feature above Story, so a board that treats Features as its roadmap level derives nothing here. Admitting both would count one roadmap item twice whenever a CapEx Epic contains CapEx Features.Roadmap Epics Touched
An epic is touched when at least one in-window task was attributed to it by the classifier. Attribution comes from the classifier's epic output, not from the tracker's epic field — because that field is far too sparse to compute coverage from. On the reference window only 12 of 105 tasks carried an epic link at all, and three of those pointed at a programme epic while one pointed at an epic that was not in the roadmap set.
A reading of 6 of 26 is not a failure grade. It is a prompt for one specific conversation: were the other twenty deliberately deferred, or did nobody notice?
Board Elements Worked On
The same query, asked from the other end: which tasks did the team demonstrably work on that never appeared as a row on this board?
This is why Team Focus reads synced tracker history rather than board rows. A view built on board rows would have inherited exactly the blind spot it exists to expose. The board defines who and what scope; the tracker history defines the task set.
A large gap here is not necessarily a problem — plenty of teams run their day-to-day in Jira and use the board for reporting. It becomes a problem the moment someone plans from the board, because the board is then describing about half the work.
The Focus map
A person × work-area matrix. Columns are the touched roadmap epics, followed by one column per class: Roadmap (no epic), Opex, Internal and Unclassified. Rows are people.
Four cell states over one 90-day window.
The third state is the one that earns the widget. A task accrues attention days whether or not anyone touches it, so a large hatched cell is a large amount of nothing happening — and no stacked bar or funnel anywhere else on the tab shows it. On the reference data the single biggest cell on the map was exactly that: 89 days across two tickets that never moved.
Two deliberate choices worth knowing:
- Roadmap columns share a scale with the OpEx columns. They render small because they were small; giving them their own scale would flatter them.
- Roadmap work the classifier could not pin to an epic gets its own column rather than being dropped. Discarding it silently made the map's row totals disagree with every other widget on the page.
Work with no owner is skipped — there is nobody to attribute it to. Unclassified work is not skipped: it has a column, so a person whose work nobody has classified reports days rather than an empty row that reads as idleness.
If it looks wrong
| Symptom | Cause | Fix |
|---|---|---|
| Roadmap Epics Touched reads 0 of 0 | No board row is both CapEx and an Epic | Mark your roadmap epics CapEx on the board |
| Epic coverage is far lower than you expected | The classifier could not attribute tasks to epics | Marking epics CapEx also fixes this, via inheritance |
| An ADO roadmap level is missing entirely | Your roadmap level is Feature, not Epic | Known limitation — track roadmap items as Epics, or read the class columns instead |
| Board coverage shows most work off-board | The team works in the tracker and the board is a reporting surface | Not a defect — but stop planning from the board until it closes |
| The map is nearly empty but other widgets have data | Tasks have no resolvable owner | Check identity merges in the caveats widget |
Frequently asked
- How does Deckgauge know which epics are on the roadmap?
- It derives them: a board row that is both marked CapEx and typed Epic is a roadmap epic. There is no separate list to curate and therefore nothing that can drift out of step with the board. Marking your epics CapEx is the single action that turns the coverage widgets on.
- Why does Roadmap Epics Touched show 0 of 0?
- Because no row on the board satisfies both halves of the predicate. Either nothing is marked CapEx, or the CapEx rows are tasks and stories rather than epics. Both halves matter: without CapEx, an unclassified epic joins a set whose whole meaning is "the roadmap"; without the epic filter, ordinary tasks dominate a count of epics.
- What is "board coverage" measuring?
- Work the team demonstrably did that never appeared as a row on this board. On the reference team, 51 of 105 tasks existed only in Azure DevOps and had never reached any board — the first finding of the report the view was built from was that the board did not describe what the team does.
- Why does the Focus map show large hatched cells?
- Hatching means attention days accrued with no state change in the window — a large amount of nothing happening. On the reference data the single largest cell on the map was exactly that: 89 days across two tickets that never moved. No stacked bar and no funnel surfaces it, which is why the map exists.
- Does Azure DevOps "Feature" count as a roadmap epic?
- Not today. Only work items typed Epic are admitted. Azure DevOps Agile and Scrum templates also place Feature above Story, so a team that treats Features as its roadmap level derives nothing here. Admitting both would make the denominator ambiguous whenever a CapEx Epic contains CapEx Features, counting one roadmap item twice.
Related
- Team Focus — the view these widgets sit on.
- Classifying work — how CapEx markings propagate down the parent chain.
- Attention days — the unit each cell is drawn in.
- Roadmaps — the planning view these epics also feed.
- Groups and rows — where the CapEx/OpEx column lives.
Last updated