Glossary
What is backlog bankruptcy?
The deliberate closure of an oversized backlog by finally making the decisions it contains — each item leaving as a recorded decline with a reason, a park with a review date, or a survivor someone will still argue for out loud.
It is not a purge. A mass delete teaches requesters nothing and the requests come back. A 400-item backlog is 400 unrecorded nos — requests refused in practice without anyone saying so — and bankruptcy converts them into decisions that exist on the record and stay made.
Backlog bankruptcy vs grooming vs a purge
Backlog grooming refines and re-orders the items a team intends to keep; it assumes they belong there. A purge deletes items by age, which destroys the record and teaches requesters only that the queue is where requests go to disappear — so the needs come back, and this time they arrive already escalated.
Bankruptcy is neither. It treats the backlog as what it has become — a pile of decisions nobody made — and makes them, one item at a time, with the result recorded where the requester can see it.
How to run a backlog bankruptcy
Put the people who can speak for the work in a room — the delivery leads and whoever owns the product direction — and walk the backlog oldest first, in time-boxed sessions. Every item leaves with one of four results: a duplicate or dead item closed as housekeeping; declined, with a one-line reason the requester can read; parked, with a review date or an explicit decision to park it indefinitely; or surviving, because someone in the room will argue for it out loud, now.
That last test is the one that makes the exercise work. "Might this be useful?" saves everything, because everything might. "Will anyone here make the case for it?" separates what the organisation still wants from what it has already declined in practice. Then send the declines back to their requesters: a no that can be contested is worth more than a maybe that cannot be found.
Keeping the backlog from refilling
A bankruptcy that changes nothing at the door is followed by another one. Two changes keep it clean: a bar at intake, so requests that state no need and no consequence go back with a question while the requester still has the context; and a cheap no, so declining a request on arrival is a one-sentence act rather than something saved for the next clear-out. Parked items then need their review dates honoured, or the park becomes the new backlog.
Related terms
- Demand — A work request that has entered the delivery lifecycle — the unit a delivery governance system tracks from intake to decision.
- Clarification brief — A short artifact that separates what is known from what is assumed from what is still an open question, produced when a raw request is shaped into a demand.
- Demand management — The practice of deciding what happens to requested work — shaping raw requests into decidable demands, refusing or parking some on the record, and committing the rest against real capacity.
This definition comes from building DeliverySheet — it takes a vague work request to a clear delivery decision, so the shape, owner, capacity, dependencies and open questions are on the table before anyone commits people or a date.
$189/month per workspace, unlimited members. 7-day free trial — card required, cancel before it ends and you're not charged. I answer the support email myself.