Team Focus: where a team's attention actually went
Team Focus is a board view that answers one question about one team over one window: did this team's work advance the roadmap, how much of it reached production, and where did their attention actually go? It reads Jira and Azure DevOps history you already sync — no timesheets, no surveys, no estimates.
The four headline tiles, above the attention split and delivery funnel.
Why a fifth tab rather than another widget
The Engineering Intelligence tab answers how well is delivery running — cycle time, review latency, DORA. Team Focus answers a different question that leadership asks at the end of a quarter and that no flow metric addresses: we spent a quarter of engineering on something; what was it?
Those two questions need different denominators. Flow metrics divide by tickets. Focus divides by attention — calendar days a task spent in a working state — because a team can close a great many small defects and move the roadmap not at all, and a ticket count reports that as a good quarter.
How do I add the Team Focus tab?
Open a board that has a Jira or Azure DevOps source attached. On the Board tab you'll see a banner offering the Team Focus preset:
Applying it creates a new view of type Focus with all twelve widgets laid out, and switches you to it. It does not touch your Board, Roadmap or Intelligence views. The banner disappears once the preset has been applied to that board.
The tab uses the same board period picker as the Intelligence dashboard — 7d / 14d / 30d / 90d / Custom — and every widget on it defaults to a 90-day window.
What you need connected
| Input | Where it comes from | Required? |
|---|---|---|
| The task set | Synced Jira and/or Azure DevOps history | Yes — at least one |
| Who counts as the team | The board's org-tree node | For the per-person widgets |
| Identity merges | Developer profiles and the identity map | Automatic |
| The window | The board period picker | Defaults to 90 days |
| The roadmap epic set | Board rows marked CapEx whose type is Epic | Only for epic coverage — see Roadmap coverage |
Everything except the last row is already true of any board with a source attached. That is the design intent: configuration is refinement, not a gate.
The twelve widgets
The preset lays them out in four bands — headline tiles, then charts, then people, then the audit trail. Each widget name links to its own reference page: what it measures, the arithmetic with a worked example, how to read it, and how to verify it against the raw rows. The Method column links to the concept behind it, which several widgets share.
| Widget (full reference) | What it shows | Method |
|---|---|---|
| Roadmap Focus | Share of attention days on roadmap / CapEx work | Classifying work |
| Landed in Production | Share of touched features that reached production | Delivery stages |
| Never Moved | Tasks with zero state changes in the window | Attention days |
| Roadmap Epics Touched | Epics that received at least one task, of the derived set | Roadmap coverage |
| Where the Attention Went | Stacked attention days per person, by class | Attention days |
| Where the Work Ended Up | The five delivery stages | Delivery stages |
| Focus Map | Person × epic matrix — moved, parked, owned-but-zero, nothing | Roadmap coverage |
| Person by Person | Tasks, never moved, in production, unshipped, working days, attention split | Attention days |
| Board Elements Worked On | Tasks the team worked that never reached this board | Roadmap coverage |
| How Work Was Classified | CapEx / rule / model / human verdict counts | Classifying work |
| Every Task, and Why | The full ledger, filterable, with each classification's reason | The ledger and caveats |
| Method & Caveats | Generated statement of what this render actually did | The ledger and caveats |
Two grains on one page, on purpose
This trips people up on first read, so it is stated in the caveats widget on every render: the delivery funnel and the shipped ratio count features; every other figure counts issues.
A "feature" is an issue rolled up to the top-level item it hangs under, so work on a sub-task counts for its epic. Without that rollup, a cancelled epic with eleven cancelled children scored twelve points in the funnel, and an epic whose children were being actively worked read as idle because nothing had changed its own status. On the reference board, 828 issues roll up to 85 features.
The two totals are not meant to match, and the caveats widget names both numbers so a reader does not report the difference as a bug. Full mechanics in Delivery stages.
The honesty layer, and why it is not optional
Team Focus reports on people's work, so a wrong number is not merely inaccurate — it is unfair to a named individual. Five guards are built in and cannot be switched off:
- A start date is never presented as idleness. If someone's first recorded activity falls inside the window, every rate for them runs from that date. On the reference window this took one engineer from an apparent 38% active days to a true 75%.
- Zero is never a finding. An expired Jira token does not return an error on the search endpoints — it silently downgrades to anonymous and returns an empty result. A zero-task result is reported as a source or scope failure, never as an idle team.
- Reviewing is real work. Ticket counts carry a printed note that reviewing, mentoring, incident response and meetings appear in none of them. On the reference window the team lead showed 16 tasks and 0 in production while opening more pull requests and casting more reviews than anyone he managed.
- Every classification is contestable. Each row prints the one-line reason that produced it, and an editor can override it.
- The caveats are generated, not authored. A caveat appears only when it applies to this render, so the block does not become boilerplate that stops being read.
Who can see and change what
| Action | Required board role |
|---|---|
| Open the Team Focus tab and read every widget | Viewer |
| Read the stage map configuration | Viewer |
| Edit the stage map | Editor |
| Override a task's class in the ledger | Editor |
| Run the advisor classification pass | Editor |
Overrides are stored per organisation, so a call made on one board is honoured on every board that sees the same task. See Access control for how board roles are granted.
If it looks wrong
| Symptom | Cause | Fix |
|---|---|---|
| Every figure is zero | Source credentials expired, or the board's scope matches nothing | Check connection health — never read this as an idle team |
| The middle two bars of the funnel are empty | Your tracker's states are not in this board's stage map | Map them — the caveats widget names the unmapped states |
| Roadmap Epics Touched reads 0 of 0 | No board row is both marked CapEx and typed Epic | See Roadmap coverage |
Most tasks show class ? | No rule matched and no advisor run has reached them | Run the classifier or add rules |
| The funnel total and the ledger total differ | Expected — features versus issues | Read the "Two grains" caveat; both numbers are stated |
Frequently asked
- What does the Team Focus view answer?
- Three questions about one team over one window: how much of their attention went to roadmap work rather than defects and internal technical work, how much of what they touched actually reached production, and which roadmap epics received nothing at all. Every figure is derived from Jira and Azure DevOps history that already exists — nothing is entered by hand.
- Do I have to configure anything before the Team Focus tab is useful?
- No. A board that already has a Jira or Azure DevOps source attached renders a useful Focus tab the first time you open it. Sources, people, identity merges and the reporting window all come from what the board already knows. Configuration — the stage map, classification rules, marking epics CapEx — refines the answer rather than gating it.
- Is Team Focus a productivity score for individual engineers?
- No, and it is built to resist being read as one. Ticket counts carry a printed warning that reviewing, mentoring, incident response and meetings appear in none of them. A person whose first recorded activity falls inside the window has every rate computed from their own start date instead. Attention days are labelled a share-of-attention proxy, never effort or FTE.
- Where does Team Focus get its task list from?
- From ClickHouse — the synced Jira and Azure DevOps history — not from the rows on the board. On the reference team, 51 of 105 tasks the team actually worked had never appeared on any board. Reading board rows would have inherited exactly the blind spot the view exists to expose, so the board defines who and what scope, and the tracker history defines the task set.
- What does Team Focus deliberately not measure?
- Lines changed and pull-request size. Azure DevOps reports zero additions and deletions on nearly all pull requests and counts files rather than lines, so any metric built on it would be wrong. Both are omitted rather than estimated, and the Method and caveats widget says so on every render.
Related
- Classifying work — how a task becomes roadmap, OpEx or internal technical, and who decided.
- Delivery stages — the five stages, the stage map, and aborted work.
- Attention days — the unit every share on this tab divides by.
- Roadmap coverage — the epic denominator, the focus map, and work that never reached the board.
- The ledger and caveats — the audit trail, overrides, and what is deliberately not measured.
- Engineering Intelligence — the other analytics tab, and how the two differ.
Last updated