Tickets that never moved: finding work that is stalled, not slow
Never Moved counts the tasks that recorded no state change at all in the window. It is the cheapest honest signal on the Team Focus view, and it is the one that most often explains why a board that looks full is delivering nothing.
| 23 / 74 |
| tasks with no state change at all |
| A task can hold attention days without anyone touching it. |
The tile, with the pairing that makes it mean something.
What it measures, and where the data comes from
The population is every issue the synced source returned for the window, from Jira and Azure DevOps, after de-duplication. For each one, the transition history is read and the transitions falling inside the window are counted. A task with zero is a task that never moved.
Two exclusions matter:
- Only real transitions count. A comment, a field edit, a re-assignment or a sprint change is not movement. The question is whether the work progressed through a state, not whether the record was edited.
- Migration bursts are filtered out. A bulk import writes a wave of changelog entries at the same instants, attributed to whoever ran it. Counted as movement, those would make a task untouched for a year look active — and would quietly promote it from parked to moved, inflating the roadmap share. A migration cutoff discards them.
How the number is calculated
It is a count and a total, not a rate — deliberately, because the denominator is what makes it readable. Over a window of 1 April to 30 June:
| Task | Transitions recorded | In window | Never moved? |
|---|---|---|---|
| PLAT-118 | 12 Apr, 3 May, 28 May | 3 | no |
| SUP-991 | 2 Apr … 19 Jun (9 total) | 9 | no |
| PLAT-31 | 14 Feb (before window) | 0 | yes |
| INF-77 | 7 May — migration burst | 0 | yes — burst excluded |
| PLAT-204 | none ever | 0 | yes |
Transitions inside the window decide the count.
Three of five never moved, so the tile reads 3 / 5. The tile turns red when the never-moved share passes a quarter of the population — here 60%, well over.
INF-77 is the case the migration cutoff exists for. It has a transition dated inside the window, and it still counts as never moved, because that transition was written by an importer rather than by anyone doing the work.
PLAT-31 and PLAT-204 look identical in this column and are completely different situations: one is in a working state and stalled, the other has never been started. The count cannot separate them — the ledger's raw-state column can, and that is why the two are always read together.
PLAT-31 can appear here as one never-moved task and simultaneously hold the largest block of attention-days in the window. Both are true, and the combination is the point: it is a large amount of nothing happening. Focus Map is where that becomes visible, as a hatched square.How to read it
Read the ratio, not the count. Twenty-three never-moved tasks out of 500 is background; 23 out of 74 is a third of the board holding still. A quarter is the threshold at which the tile changes colour, and it is a reasonable place to start caring.
Then find out which kind of stillness it is, because the count merges two problems with opposite fixes. Tasks in a working state with no transitions are aging work in progress — someone started them and stopped. Tasks in a not-started state are an untended backlog. The first is a focus and WIP-limit problem; the second is a grooming problem, and treating one as the other wastes the effort.
Finally, check the distribution. Never-moved tasks concentrated on one person is a workload or blocker problem for that person. Spread evenly across the board, it is a process problem — usually too much work started in parallel.
What it tells you over time
The same task appearing here across consecutive windows is the strongest signal this widget produces. One quiet quarter is explicable; two is a decision nobody has made. Those are the honest candidates for closing before the next planning round, and closing them is what stops them distorting every other figure on the view — a parked task inflates attention-day denominators and drags the roadmap share around without ever representing progress.
A never-moved share that climbs while the total task count also climbs usually means work is being started faster than it is being finished. That is a WIP problem, and it will not be solved by asking for more throughput.
For this widget: read the Moves column — every row showing 0 is one of the tasks counted here. Then read that row's State column alongside it: a working state means aging WIP, a not-started state means an untended backlog item, and the two need different responses.
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. A full board that is delivering nothing
| Figure | Value |
|---|---|
| Never moved | 23 / 74 |
| Landed in production | 19% |
| Largest single Focus Map cell | 89 days, hatched |
A third of the board still, and where the days went.
What you're seeing: 31% of the board recorded no movement, delivery is at 19%, and the single largest concentration of attention on the map is hatched — 89 days across tickets that never moved. The board is holding work rather than progressing it, and nearly all of the attention the view can see is going into tickets that are not advancing.
How to react: this is a work-in-progress problem, and adding throughput pressure will make it worse by starting even more in parallel. The board is already the evidence: 74 tasks in flight against a team that finished 19% of its features.
2. Never-moved concentrated on one person
| Person | Tasks | Never moved | In prod |
|---|---|---|---|
| Engineer A | 14 | 1 | 7 |
| Engineer B | 12 | 2 | 6 |
| Engineer C | 19 | 15 | 1 |
| Engineer D | 11 | 1 | 5 |
The board-level count, decomposed.
What you're seeing: the board-level 23/74 is not a board-wide process issue at all — 15 of the 23 sit with one person, who also has the most tasks and the fewest in production. Read as a board average this would have prompted a WIP limit for everyone; read per person it is one situation.
How to react: go and ask, and go in assuming a blocker rather than a performance problem. Nineteen open tasks with fifteen untouched is far more often someone drowning, waiting on a dependency, or absorbing interrupt work that never gets ticketed than someone underperforming.
Frequently asked
- How do I find tickets that never moved?
- Never Moved counts tasks that recorded no state change at all inside the window, out of the total. It counts real transitions only — a bulk-migration burst is excluded, so an import that rewrites changelog entries at one instant cannot make a year-old task look active.
- How is this different from a stale backlog item?
- A stale backlog item was never started. The tasks this widget counts are frequently in a working state — they are accruing attention-days while nothing happens to them, which is aging work in progress rather than an untended backlog.
- Why does a task that never moved still show attention-days?
- A task accrues attention-days for sitting in a working state whether or not anyone touches it. That is deliberate: the parked-versus-moved distinction can only be made once both numbers exist, and a large block of days with no movement is exactly the finding.
- What counts as movement?
- A genuine state transition recorded in the window by Jira or Azure DevOps. Comments, field edits and assignee changes are not transitions, and changelog entries written in bulk by a migration are filtered out by a cutoff so they cannot be mistaken for activity.
Related widgets
- Focus Map — draws never-moved attention as hatched squares, the only view where its size is visible.
- Person by Person — the same count, per person.
- Roadmap Focus — excludes these tasks from its fraction, and reports how many days it dropped.
- Every Task, and Why — the Moves column, task by task.
- Method: Attention days.
- Back to the widget reference.
Last updated