Half Your 'In Progress' Is Dead. The Board Hides It.
YOUR BOARD IS LYING
Sort your board by last-updated and count the silence. Stale work in progress is paid-for delivery dying quietly - how to find it, clear it, and keep it gone.
A late-night pattern midweek - worth a conversation, not a scorecard.
Illustrative example
TL;DR: Your board's "In Progress" column is lying to you. Some of those cards are work; the rest are tombstones, started, stalled, and silently abandoned while the standup ritual keeps saying "still on it." "Half" is a hypothesis, not an accusation: sort your board by last activity and your own data will give you your own number. Then run the fifteen-minute sweep below. It's free, it's blameless, and it will change what your next sprint plan looks like.
You know the column. Fourteen cards in "In Progress." A team of six. Nobody finds that arithmetic strange anymore, because the board has looked like this for months. Every card, when you ask about it, has a story. Waiting on design. Blocked on the migration. I'll get back to it after the release.
The test the board never runs on itself: when did each of those cards last move? Not "when did someone mention it." When was the last commit, the last PR event, the last ticket edit? Boards sort by status. Status is a claim. Timestamps are evidence, and the two disagree more than anyone wants to admit.
The board shows position. It hides velocity.
A Kanban card in "In Progress" looks exactly the same whether it moved an hour ago or in March. That's the design flaw: the board is a map of where work is, with no dimension for whether it's still alive. So a column quietly accumulates the walking dead: items that were real work once, got interrupted, and never resumed. The daily ritual keeps reading the column as a to-do list. Part of it is a graveyard with optimistic labels.
This isn't a hygiene nitpick. It's a delivery problem with a measurable price:
- Every open item pays a context tax on resumption. Parnin & Rugaber studied 10,000+ programming sessions and found only about 10% of interrupted sessions resume editing within a minute; roughly 30% take over half an hour to get back to writing code. A card that's been cold for six weeks isn't "80% done." It's 80% done minus the cost of re-deriving everything its author has since forgotten. That context-searching burden is the developer norm: in the 2024 Stack Overflow survey, 61% of professional developers reported spending more than 30 minutes every day just searching for answers or solutions.
- Stale WIP is invisible inventory. The elapsed-time spread between fast and slow teams is enormous. LinearB's benchmarks across 8.1M+ pull requests put elite cycle time under 25 hours (p75) and flag over 161 hours as needing focus, and DORA's 2024 tiers run from under a day of lead time (elite) to one-to-six months (low). What fills that gap is work sitting still. Zombie items are the extreme case: they've left the flow entirely but still count as flowing. As long as they're on the board, your cycle time and lead time numbers describe a fiction.
- It corrupts every decision built on the board. Sprint planning assumes the In Progress column is nearly done, so it under-commits new work or - worse - piles new work on top, and the sprint ends with the work not ending, again. Your standup spends its minutes on cards nobody will touch this week. Your stakeholder updates quote a column count that includes March.
Notice what the zombie column does to people, because this is a system problem wearing a personal costume. Every engineer with a stale card attached to their name carries low-grade guilt about it, mentions it defensively in standup, and privately knows it's dead. The board has turned a planning failure into fourteen small personal failures. Clearing it is an act of mercy.
The free cure: a fifteen-minute zombie sweep
No tooling to buy, no process to adopt. One sort, one honest pass.
- Sort "In Progress" by last activity, oldest first. Your tracker can do it; if the tickets are unreliable,
git log --branches --sinceon the linked branches is the backup truth. (If ticket timestamps and reality have fully parted ways, you have a Jira hygiene problem compounding this one. Fix the sweep first, the hygiene second.) - Draw the line at two weeks of silence and count what's below it. That count, divided by the column total, is your number. Half is the hypothesis this article's title makes; your board will confirm it, beat it, or embarrass it. All three outcomes are useful.
- Triage every cold item into alive / parked / dead. Alive means someone will touch it this week; it stays. Parked means there's a written reason and a wake-up condition; it leaves In Progress for a waiting state, with the reason on the card. Dead means nobody can say when it resumes. Close it. The branch survives; reopening is one click; the only thing you lose is the illusion.
- Cap the column so it can't refill. The sweep treats the symptom; the disease is starting too much at once. That's what WIP limits are for: start less, finish more. The limit only holds if the queues work eats while in progress get fixed too (a review nobody picks up is the classic - why reviews sit is its own diagnosis), or the column just goes stale again with fresher timestamps.
- Re-run the sort monthly. Fifteen minutes. If the stale count is falling, your flow efficiency is genuinely improving in a way no velocity chart would show you.
How you'd actually see this in Busfactor
The sweep is a manual biopsy, and its weakness is the same as every manual ritual: it happens while someone remembers to care, and stops the month attention moves elsewhere. Busfactor's job is to make the timestamps watch themselves. It connects to what you already run (GitHub, your tracker, CI), and its stuck-and-zombie detection surfaces stale WIP, aging branches, and PRs rotting in queues continuously, from the same event data your sweep would read, with every flagged item linked to the actual ticket and branch so nobody argues with a summary statistic. The same events feed the cycle-time anatomy view (pickup, review, merge, deploy), so you see not just that work went stale but which stage keeps orphaning it - the difference between feeling slow and knowing where the weeks die. Stale WIP is the board lying about work that started. Its mirror image is the backlog lying about work that never will: see your backlog is a graveyard.
The honest limits, because they matter: Busfactor reads events, not minds. It can tell you an item has been silent for 41 days; it cannot tell you whether that silence is abandonment or a deliberate pause your team agreed on in a meeting. So stale items surface as questions with receipts, and a deliberately parked item with a written reason is a perfectly good answer. It also can't see work that never touched the tracker or the repo. The board-vs-reality conversation still has to happen with the team; the tool's job is to make sure it happens with timestamps instead of vibes.
The door
Run the sort today. It costs fifteen minutes, and the count will tell you something true about your delivery that no status meeting has. Then, if you'd rather the graveyard never regrow, get your org's free read. One connection, and the zombie column, the stage that keeps creating it, and the receipts land in front of you: the diagnosis a fractional CTO would bill a retainer for, minus the pretending.
Frequently asked
How do I find stale work in progress on my board?
Sort every 'In Progress' item by last activity (last commit, last PR event, last ticket update) instead of by status. Anything with no activity in two weeks is a candidate zombie. The board view hides this because a card looks identical whether it moved an hour ago or in March; the timestamps are the truth, and they already exist in your tracker and your git history.
Should I close stale tickets or keep them open?
Triage each one into three honest states: alive (someone touched it this week: keep), parked (a real reason to wait: move it out of In Progress and write the reason down), or dead (nobody can say when it resumes: close it). Closing a dead ticket loses nothing: the branch and the history remain, and reopening later is one click. Keeping it open costs you every day, because it distorts every metric and every standup built on the board.
Is some stale work in progress normal?
Yes: a genuinely blocked item waiting on a vendor, a compliance review, or a dependency is legitimately parked work. The dysfunction isn't that waiting exists; it's that parked and abandoned look identical on the board. If an item is waiting, it should say what it's waiting for and sit in a waiting state, not impersonate active work in the In Progress column.
What causes work to go stale in the first place?
Usually too much started at once: when everyone carries four or five items, attention rotates and the least-urgent item silently loses. Common triggers are a review that never got picked up, a mid-sprint priority change nobody wrote down, and dependencies that arrived late. WIP limits attack the cause; the zombie sweep attacks the symptom. You need both.