What do the four cell states on the Focus Map mean?

A filled square is attention-days on tasks that moved. A hatched square is days a task spent in a working state with no state change at all. A ring is work owned with zero days recorded. A dot is nothing. The hatched state is the one that earns the widget — it is a large amount of nothing happening.

Why do the roadmap columns look so small?

Because they were small. Every column shares one scale deliberately: giving the roadmap columns their own scale would flatter them, and the comparison against the OPEX columns is the entire point of putting them side by side.

What does square size represent?

Area is proportional to attention-days, on a single shared scale across the whole matrix, and each square is also direct-labelled with its number so size is never the only encoding.

Why is some work missing from the map?

Tasks with no owner are skipped, because there is nobody to attribute them to. Unclassified work is not skipped — it has a column of its own, so a person whose work nobody has classified reports days rather than an empty row that reads as idleness.

Team focus heatmap: who worked on what, and what merely sat there

A person by work-area matrix where square area is attention-days. It has four cell states, and the third is the one that earns the widget: a hatched square is time that accrued while nothing happened, and no bar chart or funnel on the view will show it to you.

deckgauge · Board · Team Focus

Person	PLAT-100	BILL-2	Roadmap (no epic)	Opex	Internal	Unclassified
Engineer A	40	·	8	12	◦	·
Engineer B	·	6	·	61	9	·
Engineer C	89 ▨	·	·	4	·	·
Engineer D	·	◦	·	18	·	31

One scale, one unit. Roadmap epics as columns, then the class columns.

▨ hatched — in a working state, never moved · ◦ ring — owned, zero days · · nothing · Square area = days, one scale

What it measures, and where the data comes from

Rows are people with owned work in the window. Columns are the touched roadmap epics first, then one column per class of work: roadmap with no epic attribution, OPEX, internal technical, and unclassified.

Cells hold attention-days — calendar days a task sat in a working state, from Jira and Azure DevOps transition history.

Two population rules:

Unowned work is skipped. There is nobody to attribute it to, and inventing an attribution would be worse than omitting it.
Unclassified work is not skipped. It has a column of its own, so a person whose work nobody has classified reports days rather than an empty row that reads as idleness.

Roadmap work the classifier could not pin to a specific epic also gets its own column rather than being dropped — silently discarding it made the map's row totals disagree with every other widget on the page.

How the number is calculated

The four cell states

Cell states

Rendered as	Means	Condition
Filled square	Days on tasks that moved	Tasks in this cell with at least one real transition in the window
Hatched square	In a working state, never moved	Tasks with zero transitions in the window, still accruing days
Ring	Owned, zero days	Tasks assigned to this person in this area with no working time recorded
Dot	Nothing	No tasks at all

Decided per cell, from the tasks in it.

A cell can hold both moved and parked work. When it does, the larger of the two is drawn and both are named in the hover label. Drawing parked whenever any existed hid a person's real work behind a single stale day.

Scale

Square side is √(days ÷ max) × 30px, with a 4px floor so a non-zero cell is never invisible — so area, not side length, is proportional to days. max is the largest single value anywhere in the matrix, which is what makes one cell comparable to any other.

The roadmap columns share the OPEX columns' scale on purposeThey render small because they were small. Giving them their own scale would flatter them, and the whole reason roadmap epics and OPEX sit in one matrix is so the comparison is unavoidable. Every square also carries its number as a direct label, so size is secondary encoding rather than the only encoding.

Worked example

Engineer C owns two tasks under PLAT-100. Neither recorded a transition in the window; between them they accrued 89 attention-days sitting in In Review.

The cell's parked total (89) exceeds its moved total (0), so it draws hatched. 89 is the largest value in the matrix, so max = 89 and this cell renders at the full 30px — the biggest square on the map. Its label reads 2 task(s) · 89 days in a working state · never moved.

That is the finding the widget exists for. On the reference data the single largest cell on the map was exactly this: 89 days on two tickets that never moved. It appears in the never-moved count as "2", in the attention totals as 89 days, and its size relative to everything else only here.

How to read it

Find the largest hatched cell first. It is the biggest concentration of nothing happening on the board, and it is the reading no other widget offers.

Then scan for a row that is all rings — someone owns work and has recorded no working time against any of it. That is usually a mis-assignment or someone who has been pulled onto something that never got ticketed.

Then scan columns rather than rows. A column with one dominant cell is a work area effectively owned by one person, which is a bus-factor problem that no per-person view will surface because it looks perfectly healthy from the row side.

Do not rank people by row total. Row totals are driven by concurrency — how many tasks someone holds open simultaneously — as much as by anything else.

What it tells you over time

Compare the shape across windows, not the values. Hatched area growing anywhere means work is being started and abandoned in place. Column concentration hardening — the same person's cell dominating the same column window after window — is knowledge concentrating, and it is worth acting on before that person takes leave rather than after.

A row that shifts from filled squares in the roadmap columns to filled squares in OPEX is someone being reassigned by circumstance rather than by decision.

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 Person filter to the row and the Class filter to the column to reach the exact tasks in a cell. A hatched cell is precisely the rows whose Moves column reads 0 — the ledger is where you find out which two tickets those 89 days belong to, and why nobody has touched them.

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. The biggest square on the map is nothing happening

deckgauge · Focus Map

Person	PLAT-100	Opex	Internal
Engineer A	40	12	6
Engineer B	14	22	9
Engineer C	89 ▨	4	·

One hatched cell dominating the matrix.

What you're seeing: the largest square on the map, and it is hatched. Two tickets under the quarter's main roadmap epic have been sitting in a working state for 89 days with no transition. Every other widget records this politely: the never-moved tile counts two, the attention split shows Engineer C with a full-looking roadmap bar. Only here is it obvious that the single biggest block of attention on the board is work that has not moved.

How to react: that roadmap epic is not progressing, and the attention-day figures elsewhere on the view are actively misleading about it — Engineer C's roadmap bar looks strong precisely because parked tickets accrue days.

Managerial playAsk about the two tickets specifically rather than about the epic, and ask what is in the way rather than for a status — 89 days in review is nearly always a dependency, a review nobody picked up, or a piece of work that turned out to be much larger than the ticket says. Any of those is fixable in a conversation and none of them is visible from the dashboard. Then check whether the epic has other children being worked at all: if this is its only activity, the roadmap coverage tile is counting it as touched on the strength of two frozen tickets, and that is worth correcting before anyone reports on the quarter.

2. A column owned by one person

deckgauge · Focus Map

Person	PLAT-100	BILL-2	Opex
Engineer A	36	·	14
Engineer B	28	·	18
Engineer C	31	·	11
Engineer D	·	74	·

Healthy rows; one column with a single occupant.

What you're seeing: three engineers share the platform epic and the support load evenly — a healthy-looking team. The billing epic has exactly one occupant, who works on nothing else. Read row by row, Engineer D looks like a focused contributor with a strong roadmap bar. Read column by column, billing has a bus factor of one.

How to react: this is the reading the matrix layout exists for, and it is invisible in every per-person widget on the view — including the scorecard, where Engineer D's row is one of the better ones.

Managerial playTreat this as a risk to schedule rather than a criticism of anyone: pair someone into the billing work now, while it is calm, rather than after Engineer D takes leave or leaves. The cheapest intervention is usually reviews — route billing changes to a second reviewer so knowledge transfers as a side effect of normal work, which costs far less than a handover project and does not need anyone reassigned. Re-read this column in two months; a second non-trivial cell appearing in it is the evidence it worked, and the absence of one means the pairing was nominal.

Frequently asked

What do the four cell states on the Focus Map mean?: A filled square is attention-days on tasks that moved. A hatched square is days a task spent in a working state with no state change at all. A ring is work owned with zero days recorded. A dot is nothing. The hatched state is the one that earns the widget — it is a large amount of nothing happening.
Why do the roadmap columns look so small?: Because they were small. Every column shares one scale deliberately: giving the roadmap columns their own scale would flatter them, and the comparison against the OPEX columns is the entire point of putting them side by side.
What does square size represent?: Area is proportional to attention-days, on a single shared scale across the whole matrix, and each square is also direct-labelled with its number so size is never the only encoding.
Why is some work missing from the map?: Tasks with no owner are skipped, because there is nobody to attribute them to. Unclassified work is not skipped — it has a column of its own, so a person whose work nobody has classified reports days rather than an empty row that reads as idleness.

Related widgets

Where the Attention Went — the same days summed per person, without the work-area dimension.
Never Moved — counts the tasks the hatched cells are made of.
Roadmap Epics Touched — which epics became columns here.
Every Task, and Why — the tasks inside one cell.
Method: Attention days.
Back to the widget reference.

Last updated 10 September 2026