Can I use this to compare engineers?

Not on its own, and the widget says so on its face. These are ticket counts only — reviewing, mentoring, incident response and meetings appear in no column here, so a manager’s row will understate their contribution and a low row is not evidence of low output.

What does each column measure?

Tasks held in the window, how many recorded no state change, how many reached production, how many are merged but unshipped, working days in the person’s effective window, and their attention split by class of work with every non-zero share named.

Why does one person show fewer working days than the window contains?

Anyone whose first recorded activity falls inside the window is measured from that date rather than the window start, and the row says so in text. On the reference data this was the difference between a person reading as 38% active and 75% active for the same work.

Why did a team lead’s row look so weak?

Because it counts tickets. On the reference board the team lead showed 16 tasks and 0 in production while opening more pull requests and casting more reviews than anyone he managed. Until review and PR counts are columns here, a low row is evidence of nothing on its own.

Per-engineer focus scorecard — and what it deliberately cannot tell you

One row per person: tasks held, tasks that never moved, tasks in production, tasks merged but unshipped, working days, and the attention split. It is the most useful table on the Team Focus view and the easiest to misuse, so the limitation comes first: these are ticket counts, and ticket counts are not contribution.

deckgauge · Board · Team Focus

Person	Tasks	Never moved	In prod	Unshipped	Working days	Attention split
Engineer A	14	1	7	2	64	68% roadmap · 22% opex · 10% internal
Engineer B	12	2	6	1	64	31% roadmap · 61% opex · 8% internal
Engineer C Measured from 2026-05-14, their first recorded ticket movement — not the full window.	6	0	3	1	33	74% roadmap · 26% internal
Team lead	16	9	0	0	64	41% roadmap · 38% opex · 21% internal

The table, with a late joiner marked in text.

Ticket counts only. Reviewing, mentoring, incident response and meetings appear in none of these columns, and a manager's row will understate their contribution accordingly — a low count here is not evidence of low output.

What it measures, and where the data comes from

Everything is at issue grain, from Jira and Azure DevOps, for issues owned by that person in the window:

Tasks — issues held in the window.
Never moved — of those, how many recorded no real state change. Red above zero.
In prod — how many reached production.
Unshipped — how many are merged but not released.
Working days — weekdays in the person's effective window. Public holidays are not modelled.
Attention split — a bar plus every non-zero class share, in percent.

This is the widget most likely to be misread as a performance rankingThe footnote is on the widget itself rather than in a tooltip, because the misreading is predictable and expensive. The columns capture ticket flow. They do not capture code review, pairing, mentoring, incident response, design work, recruitment, or any meeting — so the people who do most of those will have the weakest-looking rows on the table.

How the number is calculated

Working days, and the late-joiner correction

Working days are weekdays in [from, to). The from is not always the window start: anyone whose first recorded activity falls inside the window is measured from that date instead.

Effective window

Person	First activity	Measured from	Working days	Late joiner?
Engineer A	2 Jan (before window)	1 Apr	64	no
Engineer C	14 May	14 May	33	yes — marked in the row
Engineer E	none recorded	1 Apr	64	no — see below

Window: 1 April – 30 June.

The correction matters a great deal. On the reference window the same person and the same 21 days of work read as 38% active days from the window start and 75% from their actual first activity. The first reads as someone barely present; the second as one of the more consistent contributors. Because a start date presented as idleness is the worst error this view can make, the correction is applied before any percentage rather than offered as a toggle.

Engineer E is the deliberate limit: no recorded activity at all is not a late joiner. There is nothing to measure, and inferring a start date from silence would be the same mistake in another form.

The late-joiner note is rendered as text in the row, not as a colour or an icon, so a screen reader and a screenshot both carry it.

The attention split

The bar is scaled against the largest total across all people, and lists every non-zero class beneath it. Both details are corrections of real defects:

The bar once scaled by an A+B+C total while drawing every class, so segments could total 1000% of the track. Because the container clips, a person at 10% roadmap and 90% unclassified rendered as a solid-green 100%-roadmap row — a flattering wrong answer, which is the one kind this widget exists to prevent.
The text once read {A}% roadmap · {C}% internal, so a person at 90% OPEX reported "10% roadmap · 0% internal" — two numbers individually true that together imply the other 90% does not exist.

This table renders no legend, so that line is also the only place a class is named outside a hover label.

How to read it

Read the never-moved column first. It is the per-person version of the board-level tile and the most actionable number in the table.

Check for a late-joiner note under a name before comparing that row to anything.

Read the class-share line rather than the bar. It names every non-zero class, so it cannot be misread the way a clipped bar can.

Then stop and ask what each row's owner actually does. The team lead in the mockup above shows 16 tasks and 0 in production — and on the board this pattern came from, that person opened more pull requests and cast more reviews than anyone they managed. The row is not wrong; it is measuring something that is not their job.

What it tells you over time

Individual rows are noisy window to window, because ticket granularity varies wildly between people and between projects. The stable signals are the class mix per person and the never-moved column.

A person's never-moved count rising across two windows while their task count also rises is someone accumulating work they cannot finish — that is worth acting on early, and it is nearly always a workload or blocker problem rather than a capability one.

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 that name. Every column in their row is a count over exactly those rows, so a number that looks wrong is checked task by task — and the Moves column identifies precisely which tasks the never-moved count is made of.

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 manager's row looks like the weakest on the team

deckgauge · Person by Person

Person	Tasks	Never moved	In prod
Engineer A	14	1	7
Engineer B	12	2	6
Team lead	16	9	0

Zero in production, and it means nothing on its own.

What you're seeing: the team lead holds the most tasks, moved the fewest, and shipped none. Read as a productivity table this is the worst row on the team. In reality this person is doing the reviewing, the incident response and the mentoring — none of which is a column here — and their 16 tickets are largely placeholders they are not the one working on.

How to react: do not read this row as output at all. If you want to know what a lead contributed, the Engineering Intelligence widgets have the columns this table lacks — Reviewer Participation and Review Quality Index measure review load and review substance directly.

Managerial playNever take this table into a performance conversation without the review data beside it — a row like this one, quoted alone, is how a strong lead gets managed out. The nine never-moved tickets are still worth a look, but as hygiene rather than as output: tickets a lead holds as trackers or placeholders should be closed or reassigned, because while they sit there they inflate this person's task count and distort the board-level never-moved figure for everyone. If you circulate this widget at all, circulate the footnote with it.

2. A short row that is a start date

deckgauge · Person by Person

Person	Tasks	In prod	Working days
Engineer A	14	7	64
Engineer B	12	6	64
Engineer C	6	3	33

Half the working days of everyone else.

What you're seeing: Engineer C shipped 3 against the team's 6 and 7, on 33 working days against 64. Normalise and the gap mostly disappears: 0.09 features per working day against Engineer B's 0.09 and Engineer A's 0.11. Read raw, the row looks like half a contributor; read per working day, it is an ordinary row for someone who has been there half as long. The row carries the note explaining the halved working-day count; the raw counts do not.

How to react: the widget has already applied the correction to every rate it computes, so the risk is entirely in a human reading the raw counts and skipping the note.

Managerial playNormalise by the working-days column whenever you compare rows at all — it is in the table precisely so that comparison is possible, and ignoring it is what turns a new joiner into an underperformer on a slide. For a first window, read the class mix rather than the counts: someone whose attention is spread across three classes in their first six weeks usually means nobody gave them a focused first project, which is a useful finding about onboarding rather than about them. And if you are screenshotting this row for anyone, include the note or type the tenure in yourself.

Frequently asked

Can I use this to compare engineers?: Not on its own, and the widget says so on its face. These are ticket counts only — reviewing, mentoring, incident response and meetings appear in no column here, so a manager’s row will understate their contribution and a low row is not evidence of low output.
What does each column measure?: Tasks held in the window, how many recorded no state change, how many reached production, how many are merged but unshipped, working days in the person’s effective window, and their attention split by class of work with every non-zero share named.
Why does one person show fewer working days than the window contains?: Anyone whose first recorded activity falls inside the window is measured from that date rather than the window start, and the row says so in text. On the reference data this was the difference between a person reading as 38% active and 75% active for the same work.
Why did a team lead’s row look so weak?: Because it counts tickets. On the reference board the team lead showed 16 tasks and 0 in production while opening more pull requests and casting more reviews than anyone he managed. Until review and PR counts are columns here, a low row is evidence of nothing on its own.

Related widgets

Where the Attention Went — the attention column as a chart, with the same late-joiner handling.
Focus Map — adds the work-area dimension this table has no room for, and surfaces bus-factor risk a row cannot.
Reviewer Participation — the review load this table omits entirely.
Every Task, and Why — the rows behind one person's counts.
Method: Attention days.
Back to the widget reference.

Last updated 10 September 2026