Done Isn't Done: Your Tickets Are Running in Circles
YOUR TICKETS ARE RUNNING IN
Hover or focus to flip ↻Reopened tickets and status ping-pong are your delivery process leaking. How to count ticket loops, read them fairly, and stop the Done column from lying.
TL;DR: Every ticket that comes back from Done is work you're paying for twice, and most boards have no number for how often it happens. The pattern hides because each individual reopen has a plausible story, and nobody ever adds them up. Add them up: replay your status history, count the tickets that reopened or slid backwards, and triage the worst offenders by cause. It's an afternoon of work, it's blameless, and it usually finds a definition-of-done problem wearing a dozen ticket-shaped costumes.
There's a specific moment when a team stops trusting its own board. It's not dramatic. Someone in planning says "didn't we ship that in March?" and someone else says "it came back," and everyone nods, because things come back. That's just how the board is. PROJ-482 has been Done three times. The onboarding bug is on its fourth lap. And the standup keeps reporting progress on tickets that are, technically, progressing - in circles.
The uncomfortable arithmetic underneath the nodding: a reopened ticket isn't one unit of work that took longer. It's work you counted as finished, told stakeholders was finished, possibly demoed as finished, coming back for a second budget. Unlike a slow ticket, which at least looks slow, a looping ticket generates the appearance of throughput on every lap. The board shows motion. The motion is a circle.
The costliest tickets are the ones you closed twice
This isn't board pedantry; the research on reopened work is blunt. Shihab et al. studied re-opened bugs across major open-source projects and found that in Eclipse Platform 3.0, resolving a re-opened bug took on average more than twice as long as a bug that closed cleanly. Microsoft considered the problem serious enough to study at Windows scale: Zimmermann et al. surveyed 358 engineers and mined the Windows bug database to characterize which bugs get reopened, treating a meaningful reopen rate as a signal of instability in the system rather than an accounting quirk.
And the loop taxes more than the ticket itself:
- It double-counts your delivery. Every lap through the column inflates the numbers your sprint velocity and throughput charts report, with work that ships nothing new. If your sprint keeps ending with the work not ending, loops are one of the places the hours actually went.
- It's the tracker-grain cousin of change failure rate. DORA's research tracks how often changes to production need remediation; a ticket that bounces out of Done is the same failure signature showing up one layer earlier, in your own board's history, visible without any deploy telemetry at all. (The same-code version of this pattern, files that break, get fixed, and break again, is its own diagnosis.)
- It corrodes the one artifact everyone plans on. Once "Done" means "Done, probably," planning conversations grow a silent discount factor. That's how ticket data stops being worth reading: not through one big lie, but through a hundred small returns nobody counted.
Notice what this is not: a diligence problem. Nobody reopens tickets for fun. Each reopen is somebody honestly reporting that reality disagreed with the board, which is exactly why the count is such a clean signal. The people are telling the truth. The process is what's looping.
The free cure: replay your status history
Your tracker already stores every status transition with a timestamp. One afternoon, no new tooling:
- Export the status history for the last quarter's active tickets. Every transition, not just current status. The loops live in the history, which is precisely where the board view never looks.
- Count two events per ticket. A reopen: the ticket left Done for any non-terminal state. A backslide: it fell from an in-progress state back to a not-started one. Both are laps; sum them per ticket.
- Compute your loop share. Tickets with laps, divided by tickets active in the window. There's no published benchmark to grade yourself against (team conventions differ too much for one to be honest), so the number to watch is your own trend, quarter over quarter.
- Triage the worst ten by cause, not by name. Fix-didn't-fix points at review and test gates (rework you can measure). Closed-too-early points at a missing definition of done. Container tickets point at a convention: keep it if you choose it, but choose it. New-scope-after-close points at ticket discipline, which is fixed in a five-minute working agreement.
- Re-run next quarter. A falling loop share means your Done column is regaining its meaning, an improvement no velocity chart will ever show you, because velocity was being inflated by the loops.
How you'd actually see this in Busfactor
The manual replay is a great biopsy and a terrible habit. It happens once, changes one retro, and the loops quietly resume. Busfactor's ticket-loop detection runs the same replay continuously, straight from the status transitions your tracker already recorded: a reopen after Done or a backslide from in-progress marks the lap, laps accumulate per ticket, and a ticket crossing the threshold lands on a judged list with its reopen and backslide counts as the receipt. It sits beside the rest of ticket hygiene - zombie tickets, silent intake, board-vs-git drift - because a board that loops usually lies in more than one direction, and the fixes overlap.
The honest limits, spelled out: the detection is deterministic and it is deliberately not a verdict. Some looping tickets are rolling tickets a team runs on purpose, so every finding keeps both readings on the table. The question is whether anyone decided the pattern, or the board is just breathing. Below a minimum of active tickets it says nothing at all rather than alarming on noise, and status names it can't map to a known state category are counted and disclosed, never guessed at. And no loop is ever pinned to a person; the ticket that came back five times is a fact about your definition of done, not about whoever closed it.
The door
Pull one quarter of status history this week and count the laps. The number will either be reassuringly small, which is worth knowing, or it will explain a chunk of your delivery metrics you've been attributing to "things just take longer here." Then, if you'd rather the replay never stop running, get your org's free read. The loops, the causes, and the receipts land on one page - and Done starts meaning done again.
Frequently asked
Why do tickets keep getting reopened?
Four causes cover most reopens: the fix didn't actually fix it (a quality gap upstream: review and test let it through), the ticket was closed before it met any shared definition of done (a process gap), the ticket is being reused as a container for recurring work (a convention, not a failure, but decide it deliberately), and scope arrived after closure that should have been a new ticket. The fix differs per cause, which is why counting reopens without triaging them changes nothing.
What is a normal ticket reopen rate?
There is no credible published benchmark for tracker-grain reopen rates; team conventions differ too much for a cross-company number to mean anything, and we won't invent one. What works instead: compute your own share of active tickets that looped this quarter, then watch your own trend. A rising loop share is a real signal regardless of where the absolute number sits; academic bug-tracker studies consistently find reopened issues cost far more than cleanly-closed ones.
Should a reopened ticket count as new work?
No, and that's precisely why reopens are worth counting separately. A reopen is old work you already paid for, coming back for a second payment. Logging the return trip as a fresh ticket hides the loop and inflates your throughput with work that ships no new value. Keep the history on one ticket where the regression is real, and split genuinely new scope into a new ticket.
Is reopening a ticket ever fine?
Yes. Some teams deliberately run rolling or container tickets that cycle by design, and an occasional honest reopen beats quietly filing a duplicate. The question a loop count asks isn't 'who reopened this'; it's whether anyone decided the pattern. A ticket that yo-yos because the team chose a convention is a convention; a ticket that yo-yos because nobody agrees what Done means is a leak.