How do I see the raw data behind a Team Focus number?

Add the Every Task, and Why widget to the same board and the same period. Every other Team Focus figure is a count or a sum over its rows, so filtering it by person, class and stage isolates the exact population behind any number on the view.

What does a zero in the Moves column mean?

Nothing observable happened to that task in the window. It is why a task can hold attention-days without anyone touching it, and those rows are exactly the population the Never Moved tile counts and the Focus Map draws as hatched squares.

What does "Jira + Azure DevOps" in the System column mean?

That task existed in both systems and was merged into one row on a normalised title — keys stripped, brackets removed, punctuation collapsed. Its history came from both, so saying only "Jira" would hide that.

An audit trail for engineering metrics: every task, and why

This is the widget the other eleven point at. Every figure on the Team Focus view is a count or a sum over these rows, so when a number looks wrong, this is where the disagreement is settled — not by trusting the dashboard, and not by exporting a spreadsheet.

deckgauge · Board · Team Focus

ID	Cl	Title & classification reason	Owner	State	Delivery stage	System	Moves
PLAT-118	A	Tenant switcher Marked CAPEX on the board row.	Engineer A	Released	In production	Jira	6
PLAT-141	A	Switcher telemetry Roadmap: inherited from PLAT-100, marked CAPEX on the board.	Engineer A	In Review	In development	Jira	2
SUP-991	C	Retry storm on webhook SET BY HAND Reclassified as internal technical.	Engineer B	Done	In production	Jira + Azure DevOps	9
PLAT-31	?	Legacy import path No classifier could reach this task.	Engineer C	In Review	In development	Jira	0

Raw state beside derived stage, with the reason printed.

Showing 4 of 122. A zero in Moves means nothing observable happened to that task in the window.

What it measures, and where the data comes from

One row per task, at issue grain, for everything Jira and Azure DevOps returned for the window — including tasks that never appeared on the board.

Column	What it holds
ID	The issue key, as the source system writes it.
Cl	Class glyph: `A` roadmap/CAPEX, `B` OPEX, `C` internal technical, `?` unclassified.
Title & reason	The title, and beneath it the reason the classifier gave — the sentence that makes the class contestable.
Owner	The assignee, or an em dash when there is none.
State	The raw board state, unmapped.
Delivery stage	The stage that raw state maps to.
System	Jira, Azure DevOps, or both when the task was merged across them.
Moves	Real state changes inside the window. Red at zero.

Why raw state and mapped stage sit side by sideBecause that pairing 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. If a funnel bar looks wrong, these two columns tell you immediately whether the stage map is wrong or the underlying data is — and those have completely different fixes.

How to use it to verify a number

Three filters — person, class and stage — compose, and every Team Focus figure corresponds to a filter combination:

To check…	Filter to…	Then read…
Roadmap Focus	Class = A	the rows with a non-zero Moves count
Never Moved	—	every row whose Moves column is `0`
Landed in Production	Stage = In production	the row count (at issue grain, not feature grain)
Where the Work Ended Up	Stage = each in turn	State beside Delivery stage, to check the mapping
Where the Attention Went	Person = one name	the class of every task in their bar
Focus Map	Person + Class	the tasks in one cell; hatched cells are the `0`-move rows
How Work Was Classified	—	the printed reason and the Set by hand badge per row

Two grains, and this widget is the issue-grain oneThe ledger lists issues. Where the Work Ended Up and Landed in Production count features — issues rolled up to the top of their parent chain. So the ledger's row count will exceed those widgets' totals, and it is supposed to. Method & Caveats prints both numbers.

How the row itself is built

The classification reason

Every row carries the sentence explaining its class, and the sentence names what decided it — "Marked CAPEX on the board row", or "Roadmap: inherited from PLAT-100, marked CAPEX on the board". The inherited form deliberately reads as inherited and names the row it came from, so a wrong classification stays contestable rather than looking first-hand.

A class a person set is badged Set by hand in the row text, not only by a coloured glyph — colour and a ring are unavailable to a screen reader, and that row is asserting that a person overruled the board's own CAPEX flag.

How an override survives the next sync

A hand-set class is stored against a content fingerprint, not against an issue id: the title and description are normalised the same way and hashed. That is what lets an override survive Jira/ADO de-duplication, an id change, and the next window.

How two systems become one row

A task tracked in both systems is merged on a normalised title — issue keys stripped, bracketed tags removed, punctuation collapsed, everything lowercased. Digits survive deliberately: a title like checkout 666 errors is about error 666, and dropping the number would merge unrelated tasks.

A merged row keeps its Jira key, so the System column says "Jira + Azure DevOps" rather than just "Jira" — otherwise the row would hide that the task was tracked in both and that its history came from both.

Correcting a classification

With edit rights on the board, the class glyph is a picker: change it in place and every widget on the view follows. The override is recorded as provenance HUMAN, badged in the row, and counted in How Work Was Classified — so a correction is attributable rather than anonymous.

This is the intended way to fix a wrong number. Arguing with a percentage changes nothing; correcting the row it came from changes the percentage.

Example situations

1. A stakeholder does not believe the roadmap share

What you're seeing: Roadmap Focus reports 38% and someone senior is certain it was higher. Nothing about the percentage itself can settle this.

How to react: filter the ledger to Class = A and read the rows together. One of three things happens, and all three are progress: the rows are right and the stakeholder's recollection included work that was classified OPEX; the rows include tasks that are not really roadmap, which is a classification error you can fix in place; or roadmap work is missing entirely, which sends you to Board Elements Worked On to see whether it ever reached the board.

Managerial playDo the filtering with them in the room rather than sending a corrected number afterwards — the reason column is what converts a dispute about a percentage into a review of specific tickets, and that conversation is almost always shorter. Expect to find real misclassifications and fix them there and then; a stakeholder who watches you correct two rows and re-read the number will trust the next figure far more than one who receives a defence of the first. Note what the exercise costs you: if most rows were decided by the model rather than by the CAPEX field, this will keep happening until the board is marked up.

2. A funnel bar that does not match reality

deckgauge · Every Task, and Why

ID	State	Delivery stage	Moves
PLAT-208	Ready for QA	Not started / stalled	4
PLAT-211	Awaiting release	Not started / stalled	7
BILL-40	Client review	Not started / stalled	3

Filtered to Stage = Not started / stalled.

What you're seeing: the funnel says these features never started; the ledger shows them in QA, awaiting release and in client review, each with several moves. The pair of columns makes the cause unambiguous — this board's stage map does not recognise those three states, so they fall through to not-started.

How to react: this is a mapping problem, not a data problem, and it is two minutes of work. The moves count is the tell: genuinely unstarted work does not have four transitions.

Managerial playFix the stage map from the link on the funnel itself, and make the QA and client-review calls deliberately with the team — whether QA counts as in-development or waiting-to-ship decides who owns that queue, so it is worth five minutes of discussion rather than a guess. Use the rule that the boundary is the merge: if the engineer is still on the hook, it is in development. Then check the funnel again and tell whoever saw the old version, because a not-started bar that collapses from 62% to 5% will otherwise read as someone massaging the numbers.

Frequently asked

How do I see the raw data behind a Team Focus number?: Add the Every Task, and Why widget to the same board and the same period. Every other Team Focus figure is a count or a sum over its rows, so filtering it by person, class and stage isolates the exact population behind any number on the view.
Why does the ledger show the raw state next to the delivery stage?: So you can see how a state was interpreted and argue with it, rather than being handed a stage and asked to trust it. If a funnel bar looks wrong, the pair of columns tells you whether the mapping is wrong or the data is.
What does a zero in the Moves column mean?: Nothing observable happened to that task in the window. It is why a task can hold attention-days without anyone touching it, and those rows are exactly the population the Never Moved tile counts and the Focus Map draws as hatched squares.
What does "Jira + Azure DevOps" in the System column mean?: That task existed in both systems and was merged into one row on a normalised title — keys stripped, brackets removed, punctuation collapsed. Its history came from both, so saying only "Jira" would hide that.

Related widgets

Method & Caveats — the same population described in aggregate, including what the window could not measure.
How Work Was Classified — the reason column, counted by deciding authority.
Never Moved — the zero-move rows, counted.
Focus Map — the same rows as a person × work-area matrix.
Method: Ledger & caveats and Classifying work.
Back to the widget reference.

Last updated 10 September 2026