Your Backlog Is a Graveyard. Leadership Plans on It.
LEADERSHIP PLANS ON IT
Hundreds of open tickets nobody will ever do, requests that die unanswered, and plans built on that fiction. The case for a measured backlog bankruptcy.
The band we grade against.
Illustrative example
TL;DR: Your tracker holds hundreds of open tickets that everyone privately knows will never be done, while a growing share of real work arrives through DMs and hallway asks and never becomes a ticket at all. The board describes a fictional org, and that fiction is what your roadmap, your sprint plan, and your exec updates are built on. The cure is measured: count the dead, close them honestly in bulk, and give incoming requests a front door with a response SLA. Then keep both numbers watched so the graveyard never regrows.
Open your tracker and look at the number next to "Open." Now ask the only question that matters about it: of these, how many will a human being actually do? Every engineering leader knows the honest answer is a fraction. Every planning meeting proceeds as if it were the whole number.
Meanwhile, the newest real work in your org isn't in the tracker at all. It's in a DM to your most helpful engineer, or a Slack thread that ends with "I'll just do it." Your team learned this routing honestly: they watched what happens to filed tickets. The backlog is where requests go to die, so requests stopped going there.
The board describes an org that doesn't exist
A backlog was supposed to be a plan. Sedano, Ralph, and Péraire's ICSE study of the product backlog, built on two-plus years of participant observation across eight projects, describes it as a model of the work to be done, the shared object that bridges deciding and building. That's exactly why decay is expensive. When the model rots, everything downstream inherits the rot.
The same research group's waste taxonomy names mismanaging the backlog as one of the nine core wastes of software development. That covers backlog inversion, where engineers pull stale, low-value items because nobody re-prioritized, and duplicated work, where two people quietly build the same thing. A graveyard backlog actively generates wasted engineering time.
The fiction compounds in three directions at once:
- Down: the dead crowd out the living. Sprint planning against a board of hundreds means every real decision starts with an archaeology dig, and prioritization theater replaces prioritization. That's a signature move of the feature factory: Cutler's twelve signs pointedly include infrequent acknowledged failures and scrapped work. An org that never closes anything as "won't do" is an org that never admits a decision.
- Sideways: started work stops moving and nobody says so. Tickets that entered In Progress weeks ago and went silent inflate your apparent throughput, and they're why the sprint ends with the work not ending. Stale WIP, the In-Progress-column variant of this disease, has its own sweep; the graveyard is what happens when the same neglect spreads to the whole tracker.
- Up: leadership plans against the fiction. Your delivery forecasts, your "when will it ship" answers, and your exec updates all quote a board that misstates both supply and demand. That's how a leader ends up unable to tell the CEO when anything will land: the instrument was never calibrated. Honest delivery metrics start with an honest substrate, and DORA's research keeps finding enormous spreads between the fastest and slowest orgs. Those spreads are made of exactly this kind of invisible waiting and unacknowledged dead weight.
The intake half is the quiet killer. Every request that dies unanswered teaches its requester to route around the system next time. The work still happens. It happens invisibly, as unplanned glue work landing on whoever is easiest to DM, while the tracker's picture of demand drifts further from reality. Leadership then staffs, budgets, and prioritizes against the drifted picture.
Backlog bankruptcy, run like an adult
Run it as a measured reset with numbers attached. One afternoon:
- Count the fiction first. Three numbers: open tickets untouched for six-plus months; tickets started three-plus weeks ago with nothing moving since; requests from outside the team that never got any response. Write them down - that before picture is honestly the most truthful delivery report your org has produced in a while.
- Declare bankruptcy on the first pile. Bulk-close everything untouched past your threshold, with a comment: closed in a backlog reset, reopen if it still matters. The few that come back were alive all along. That is information, and so is the silence about the rest.
- Triage the zombies in one meeting. For each started-but-motionless ticket: finish it, split it, or close it explicitly. Some will turn out to be done-but-never-closed, which means the board was also lying in the optimistic direction. Jira hygiene is the standing discipline; this meeting is the debt payment.
- Give intake a front door that answers. One named intake owner, one SLA: every request gets a first response inside a week, whether that's yes, no, or "scheduled for X." The SLA is what makes filing a ticket rational again. Without it, the DM economy returns within a quarter.
- Cap the inflow. The graveyard grew because accepting work cost nothing. Make acceptance a decision again: WIP limits for started work, an explicit "we won't do this" path for the rest. Saying no in writing is the cheapest delivery optimization there is.
How you'd actually see this in Busfactor
The reset is a one-time act of honesty; the graveyard regrows wherever counting stops. Busfactor watches both failure modes continuously from your tracker and git data, on its ticket-hygiene surface. Zombie tickets (started three-plus weeks ago, still open, nothing moving since) show up as a count with a ranked receipt list of real ticket keys and titles, so the triage meeting starts with a list instead of a search. Silent intake is its own metric: requests filed by people who don't ship code to your repos - the support lead, the sales engineer, the CEO - that have sat sixty-plus days without being started.
Both thresholds are org-configurable and both numbers are trended. Point a watchdog at either and the crossing arrives as an alert with receipts instead of a planning-meeting surprise six months later. The prescriptions ship attached and stay concrete: triage the aging open tickets (finish, split, or explicitly close them), and assign an intake owner so requests get a first response inside the week.
The honest limits: the request flag is a disclosed heuristic. It identifies tickets created by people outside your shipping team, and it says so rather than posing as ground truth. No tool can see the hallway ask that never became a ticket, a commit, or anything else; what Busfactor shows you is the front door's track record, which is both the measurable symptom and the reason people started routing around it. And a ticket deliberately parked with a written reason is a perfectly good answer - the zombie list is a set of questions with receipts, never a verdict on the person whose name is on the card.


The door
Count the three numbers this week: the untouched, the motionless, and the unanswered. They cost an afternoon, and they'll tell you precisely how fictional the artifact your org plans against has become. Then, if you'd rather the fiction never rebuild, get your org's free read. One connection, and the zombie list, the silent requests, and the gap between your board and your git history land in front of you, every finding with the fix attached.
Frequently asked
Should we just delete old backlog tickets?
Close, don't delete. Close in bulk, with a comment. A scoped backlog bankruptcy auto-closes everything untouched for longer than your threshold (six or twelve months is common) with a polite note: 'Closed as part of a backlog reset; reopen if this still matters.' The history survives, reopening is one click, and the handful of tickets that come back are the ones that were actually alive. What you lose is only the illusion that the other several hundred were ever going to happen.
What is a zombie ticket?
A ticket someone moved to In Progress three or more weeks ago that is still open with nothing moving since. It's a different lie than backlog bloat: an old backlog ticket overstates your options, while a zombie overstates your current throughput. Some zombies are abandoned work; some are done-but-never-closed, which means the board also lies in the optimistic direction. Both corrupt any plan that trusts the column counts.
How is silent intake different from a messy backlog?
Backlog mess is work you accepted and buried. Silent intake is work that arrived at the front door, a request filed by someone outside the engineering team, and never got any response at all. It's the more corrosive failure, because it trains requesters: after the second ticket dies in silence, people stop filing tickets and start sending DMs, and from then on a growing share of real demand never becomes visible anywhere leadership plans.
Won't closing hundreds of tickets upset the people who filed them?
Less than the silence already does. An open ticket ignored for a year is a standing false promise, and requesters know it. A closure with a reason and a reopen invitation is an honest no, which most people respect. Pair the bankruptcy with a first-response SLA on new requests (a week is achievable for most teams) and you've replaced a graveyard with a front door that answers.