The ledger and the generated caveats
Two widgets exist so the other ten can be trusted. Every Task, and Why is the audit trail — the raw tracker status sitting next to the derived stage, and every classification printed with its reason. Method & Caveats is the render's own statement of what it did to your data.
Every Task, and Why
One row per task in the window, filterable by person, class and delivery stage.
Roadmap: inherited from ACME-4, marked CapEx on the board.A. RiveraDoneIn productionjira7
Refactor or naming alignment — no roadmap outcome stated.J. OkaforIn ProgressIn developmentjira2
No classifier reached this task.S. BennetOn HoldNot startedado0
The ledger. The Cl column is a control for board editors.
The columns
| Column | What it carries |
|---|---|
| ID | The Jira key, or the Azure DevOps id. A task present in both keeps the Jira key and notes the ADO twin. |
| Cl | The class glyph — A, B, C or ?. For board editors this is a picker, not a label. |
| Title & classification reason | The task title, with the one-line reason that produced its class printed beneath it. |
| Owner | The resolved person, after identity merging on email. |
| State | The raw status from your tracker, verbatim. |
| Delivery stage | The stage that state maps to on this board. |
| System | jira or ado. |
| Moves | Real state changes in the window. 0 is what "never moved" means. |
Client Review was counted as waiting to ship and either accept it or change the map.Overriding a classification
A board editor clicks the Cl cell and picks A, B, C or Unclassified. The call is stored as a human verdict, outranks every automatic classifier, and is keyed by content rather than by id so it survives re-sync, de-duplication and the next window. Full mechanics in Classifying work.
The classification notice
Below the filters and above the table, a strip states how many tasks carry no classification and offers a single button to run the advisor over them. It sits there rather than in the filter row on purpose: it spends money against your provider and rewrites the classes every widget on the page reports, which is a thing you do, not a thing you toggle.
Method & Caveats
The caveats block is generated by the render, not written by a person. A caveat that does not apply is absent rather than greyed out — no late joiner means no late-joiner entry — because a fixed list of disclaimers gets skimmed and stops being read.
What can appear, and what each one means:
| Caveat | Appears when | What it tells you |
|---|---|---|
| Window | Always | The exact dates counted. |
| Commit window | Commit data stops before the window ends | Commit and active-day figures are bounded there. A data boundary, not inactivity. |
| Two grains | The funnel is counting features | Names both the feature count and the issue count, so the difference is never read as a bug. |
| Cancelled before starting | Any task was cancelled unworked | How many left the delivery-stage population, and why counting them either way would misdescribe the window. |
| Systems | Always | Which trackers were counted, and the task total after de-duplication. |
| Both systems | The two trackers disagree on the total | What counting one alone would have found. A window spanning a migration must count both. |
| De-duplication | Any task existed in both systems | How many were merged, and on what rule. |
| Task age | A migration cutoff is configured | Changelog entries at or before that instant are import artifacts, not work. |
| Identity | Logins were merged | How many logins resolved to how many people — and, plainly, that the view cannot show you which merges it made. |
| Late joiner | Someone's first activity is inside the window | Names the person and the date their rates run from. |
| "Approved" | An Approved state exists | How many transitions out of it led to a working state, and what that implies. |
| Unmapped states | A status is not in the stage map | Names them, and says they were counted as not started. |
| Unclassified | Any task has no class | How many, and that they are counted as their own class rather than assumed into another. |
| Attention days | Always | A share-of-attention proxy, not effort. |
| Not measured | Always | Lines changed and PR size, and why they are omitted rather than estimated. |
De-duplication, stated plainly
Jira and Azure DevOps rows are merged on a normalised title: lower-cased, tracker keys stripped, bracketed segments removed, punctuation runs collapsed. One row survives, keyed by the Jira key with the ADO id alongside, taking the earlier creation date.
On the reference window this is the difference between reporting 47 tasks and 105. A team mid-migration that counts one system reports roughly half its own work.
Task age, and the migration cutoff
A bulk migration stamps every imported ticket with the migration date and writes a burst of changelog entries at the same instants. Left alone, this makes every ticket on the board look five weeks old and freshly active.
Setting a migration cutoff on the board makes changelog entries at or before that instant count as import artifacts rather than work, and takes origin dates from the older system where a task exists in both. That is what turns "everything is five weeks old" into tasks 500–900 days old.
What the view will not do
- Write to Jira. Jira is read-only throughout Deckgauge. Overrides live in Deckgauge.
- Freeze a run. The view is live. A frozen artefact with spreadsheet and slide export is designed but not built.
- Compare boards. Fanning Focus widgets across boards comes after the single-board version is proven — see the Comparison view for what cross-board analysis exists today.
- Report lines changed. See the "Not measured" caveat.
If it looks wrong
| Symptom | Cause | Fix |
|---|---|---|
| A task appears twice | Its titles differ enough in the two systems to defeat normalisation | Align the titles, or override one row's class so both read the same |
| Everything looks recently created | No migration cutoff is set | Set one to the migration instant for this board |
| Two people were merged into one | Identity is matched on email; two accounts share one | Correct the developer profile — the caveat states that the view cannot show you which merges it made |
| The ledger is empty but tiles show numbers | An active filter — person, class or stage | Clear the filter pills above the table |
| A reason reads "inherited from …" and looks wrong | An ancestor row is marked CapEx | Mark the task itself, or override its class here |
Frequently asked
- Can I see why a task was classified the way it was?
- Yes — every row in the ledger prints its one-line reason beneath the title, alongside which classifier produced it. That is the point of the widget: the raw tracker status sits next to the derived delivery stage, so a mapping can be seen and argued with rather than taken on trust.
- What are the Method and caveats generated from?
- From what that particular render actually did. A caveat appears only when it applies to the window on screen — no late joiner means no late-joiner entry. A fixed list of disclaimers gets skimmed and stops being read; a list where every line corresponds to something that happened to this data keeps its weight.
- Which caveats always appear?
- Four. Two describe the render — the window counted, and which systems it drew on. Two are true of the method rather than of the data: attention days are a share-of-attention proxy rather than effort, and lines changed and pull-request size are unavailable. Dropping either of the last two would let someone quote a number the view cannot support.
- Can I export a Team Focus report?
- Not yet. The view is live rather than frozen — every widget re-reads the window you have selected. A frozen "run" artefact with spreadsheet and slide export is a designed but unbuilt slice; nothing in the current design forecloses it.
- Does Team Focus write anything back to Jira?
- No. Jira is read-only throughout Deckgauge, and that is a standing constraint rather than a gap. Classification overrides are stored in Deckgauge against a content fingerprint and never pushed to the tracker.
Related
- Team Focus — the view these two widgets underwrite.
- Classifying work — what the reasons in the ledger mean.
- Delivery stages — the mapping the State and Stage columns expose.
- Attention days — the proxy the caveats always name.
- How a widget gets its number — the same idea on the Intelligence tab.
Last updated