Backlog Bankruptcy: How to Declare It Without Losing What Matters

Open your project management tool right now and count the items in your backlog. If the number has three digits, you are not looking at a plan — you are looking at a graveyard. Every one of those cards is a tiny open loop in your head, a thing you once thought mattered, now mostly noise. And every time you scroll past them looking for the one task you actually need, they tax you a little.

The backlog was supposed to be a tool: a place to park ideas so you could focus on the work in front of you. Somewhere around item 80, it quietly stopped being that. Now it's a source of guilt. You don't groom it because grooming it is depressing. You don't delete it because deleting feels reckless. So it just sits there, growing, rotting, and silently making you feel behind on a project you're actually shipping fine.

There's a way out, and it's more aggressive than "spend a Saturday cleaning up." It's called declaring backlog bankruptcy.

---

How a backlog rots

A fresh backlog is honest. You have ten things to build, you list them, you start at the top. The list maps cleanly to reality.

Rot sets in through accumulation. Every bug report, every "wouldn't it be cool if," every half-formed idea from the shower gets dropped into the backlog because capturing is cheap and dismissing feels harsh. Saying "no, that idea isn't worth tracking" requires a decision; tossing it on the pile requires none. So the pile grows by addition and never shrinks by subtraction. This is the same dynamic that drives feature bloat in the products we build — except now it's eating your task list instead of your codebase.

The deeper problem is psychological. The Zeigarnik effect describes how unfinished tasks occupy your attention more than finished ones — your brain keeps open loops warm, ready to nag. A backlog is a list of open loops you have deliberately written down. A handful is fine; that's the whole point of externalizing them. But 300 open loops don't sit quietly in a database. They sit, faintly, in your head, as a diffuse sense that there is always more undone than done.

The numbers make the point on their own.

If the Pareto principle holds even loosely, most of the real value in your backlog lives in a small minority of its items. The other 80 percent are not just low-value — they are actively expensive, because you have to read past them every single time you look for the 20 percent that matter.

---

Why grooming a giant backlog is wasted work

The standard advice for a messy backlog is "groom it." Sit down, go through each item, re-estimate, re-label, re-prioritize, merge duplicates, close stale ones. It sounds responsible. It is mostly a trap.

Grooming a 300-item list is a multi-hour slog that produces a slightly-less-messy 280-item list. You will burn an afternoon making micro-decisions about tasks you will never start, and the marginal item — number 217, "consider dark mode for the settings export modal" — gets the same few seconds of your finite judgment as the genuinely important ones. That's a terrible allocation. You're spending your scarcest resource, attention, on the things least likely to ever ship.

There's a Parkinson's Law angle here too. Work expands to fill the time available, and a backlog expands to fill the storage available. As long as there is room for one more card, one more card will appear. Grooming doesn't change the dynamic — it just resets the clock on the next overflow. Bankruptcy plus a hard cap changes the dynamic. That's the difference between cleaning a room and moving to a smaller house you can actually keep tidy.

The honest move is not to triage 300 items. It's to admit the list as a unit has failed, and start over.

---

The bankruptcy procedure

Here is the whole thing. It takes about thirty minutes, not an afternoon.

Step 1 — Archive everything (don't delete)

Select the entire backlog and move it to an archive. Not the trash — an archive. The distinction is the entire psychological trick: you are not destroying anything, you are filing it. In GritShip, archived tasks stay fully searchable, so a year from now when someone asks "didn't we talk about CSV export?", you type a search and it's right there. Nothing of value is lost. The loop in your head, though, finally closes.

If your tool doesn't archive cleanly, create a project literally named "Archive" and bulk-move everything into it. Then collapse it and never look at it unless you're searching for something specific.

Step 2 — Re-add only the next two to four weeks

Now rebuild. The single filter for re-adding a task is this question, asked out loud:

Would I genuinely start this in the next two to four weeks?

Most people, doing this honestly, re-add somewhere between 10 and 30 items out of hundreds. That's not a failure of the old backlog — that's proof of how much noise it was carrying. Do this from memory first; the genuinely important things come back to you without effort, because they're the open loops your brain was actually keeping warm. Then take one quick pass through the archive to catch anything you forgot. Resist the urge to "rescue" items just because you feel bad for them.

Step 3 — Rank what survived

A flat list of 20 tasks is already a thousand times better than 300, but you can do better in two minutes by assigning P1 to P4 priorities. The framework is deliberately coarse:

• P1 — do now, this is what's blocking shipping
• P2 — do soon, clearly next
• P3 — would be nice, no urgency
• P4 — eventually, if ever

Here's the rule that keeps the new backlog honest: anything that wants to be P4 forever does not belong in the working backlog at all. Send it back to the archive. P4 is a holding state for "real but not now," not a permanent parking lot. If you have a dozen P4s that have been P4 for months, you've recreated the exact problem you just escaped. For a deeper treatment of the four levels, see the P1–P4 prioritization guide.

Step 4 — Add due dates only where they're real

Slap due dates on tasks that have actual external deadlines — a client demo, a launch, a renewal. Do not put due dates on everything. A due date on a task with no real deadline is a lie you tell yourself, and a backlog full of fake deadlines is just a louder graveyard. A due date should mean "something bad or disappointing happens in the real world if this isn't done by then." If nothing happens, no date.

---

Giant backlog vs. lean backlog

The lean backlog's "cons" are really just the giant backlog's "pros" wearing honest clothes. The discomfort of saying no at capture time is exactly the decision that the giant backlog let you defer — and deferring it 300 times is how you got here.

---

Keeping it small forever

Bankruptcy is a reset, not a cure. Without new rules, you'll be back at 300 items in eighteen months. Three rules keep the new backlog lean.

Rule 1 — Cap the backlog like a WIP limit

Borrow the discipline from Kanban work-in-progress limits. A WIP limit caps how many tasks can be in progress at once; a backlog cap caps how many can be waiting. Pick a number — 20, 30, 40, whatever fits your project — and treat it as a hard ceiling. When a new idea would push you over the cap, you don't just add it. Something has to leave first. That forced trade-off is the whole mechanism: it converts "should I add this?" (always yes) into "is this better than the weakest thing already here?" (often no).

This is the same logic that makes WIP limits help you ship faster, applied one stage upstream. Constraints don't slow you down; they force the prioritization you'd otherwise avoid.

Rule 2 — Treat P3/P4 sprawl as an archive trigger

Run a quick rule of thumb: if your P3 and P4 items together outnumber your P1 and P2 items, the backlog is drifting back toward graveyard territory. The low-priority pile is where rot starts, because P3 and P4 are the comfortable place to dump things you can't bring yourself to reject. Periodically — once a month, ninety seconds — scan the bottom of the list and archive anything that's still sitting there. You won't miss it. If you do, it's searchable.

Rule 3 — The "would I start this today?" test at capture

The strongest version of the discipline happens before the item ever enters the list. When you go to add a card, ask: would I start this today if it were the only thing in front of me? If the answer is a clear no, the card goes straight to the archive, not the backlog. This sounds harsh, but it's just doing the bankruptcy decision continuously instead of in one painful batch every two years.

---

But what about the genuinely good ideas?

This is the objection everyone raises, and it deserves a real answer: won't I lose the one brilliant idea buried at item 247?

No — and here's the structural reason. Good ideas are persistent. A genuinely valuable feature or fix doesn't get written down once and forgotten; it comes up again. A user asks for it. You hit the pain yourself. It nags you in the shower. The ideas that only ever appeared once, never to resurface, are by definition the ones that didn't matter enough to stick. Bankruptcy filters on persistence, and persistence is a remarkably good proxy for value.

And the archive is your safety net underneath all of it. You didn't delete item 247. It's sitting in a searchable archive. If it was real, you'll search for it the day it becomes relevant — and it'll be there, exactly where you left it. The only thing you've removed is its ability to clutter your daily view and tax your attention while it waits.

This is the same philosophy behind running a side project without losing your mind: your tool should reflect what you're actually doing this month, not serve as an archaeological record of everything you ever considered. The record can exist — it just shouldn't be the thing you look at every morning.

If you want a more deliberate framework for deciding what's worth keeping in the first place, the approach in how to prioritize feature requests as an indie hacker pairs naturally with backlog bankruptcy: bankruptcy clears the board, and a prioritization rubric keeps you from refilling it with noise.

---

What a healthy backlog looks like afterward

When you're done, open your tool and look. The backlog fits on one screen. Every item is something you can imagine starting this month. P1s are at the top, P4s are scarce and provisional. There are a handful of real due dates and no fake ones. You can find the next task in under five seconds, and scanning the list produces a feeling of clarity rather than dread.

That's the whole goal. A backlog is supposed to make the next decision easy. A 300-item backlog makes every decision harder. A lean, honest, capped one — rebuilt from bankruptcy and defended with a few simple rules — does its actual job: it tells you what to do next, and then it gets out of your way.

Frequently asked questions

Isn't archiving everything just deleting with extra steps?

No — and the difference is the entire point. Deleting removes data permanently and creates real risk, which is why you avoid it and let the backlog grow instead. Archiving moves items out of your daily view while keeping them fully searchable. You lose the clutter and the attention tax, but you keep the ability to recover any item the moment it becomes relevant again. The psychological cost of archiving is near zero, which is exactly why it works where deleting doesn't.

How often should I declare backlog bankruptcy?

Ideally never again — that's what the backlog cap and the 'would I start this today?' test are for. If you enforce a hard cap and archive aggressively, the list stays lean continuously and never reaches bankruptcy territory. In practice, most people need one big reset to escape an existing graveyard, then light monthly pruning. If you find yourself needing a full bankruptcy more than once a year, your cap is too high or you're not defending it.

What's a good maximum size for a backlog?

For a solo dev or small project, somewhere between 20 and 40 items is a sane ceiling. The exact number matters less than having one and treating it as hard. The test is whether you can scan the whole list in a few seconds and feel clear rather than overwhelmed. If you can't, the cap is too high regardless of the number. Tighter is almost always better than looser.

How do P1–P4 priorities and due dates fit into a lean backlog?

Priorities rank the order you'll work; due dates mark real external deadlines. Use P1 to P4 to keep the list sorted by what matters, and send anything stuck at P4 back to the archive. Add due dates only when something genuinely bad happens in the real world if the task slips — a client demo, a launch, a renewal. A due date on a task with no real deadline is just a lie that makes the backlog louder without making it more honest.

Won't I forget the great idea I archived?

Probably not, because genuinely good ideas are persistent — they resurface through user requests, your own recurring pain, or sheer nagging. The ideas that appear once and never again are, by definition, the ones that didn't matter enough to stick. And the archive is searchable, so even the rare important-but-quiet idea is recoverable the day it becomes relevant. Bankruptcy filters on persistence, which is a surprisingly reliable proxy for value.

My team shares the backlog — can we still do this?

Yes, but do it together in one short session so it's a shared decision, not a unilateral purge. Archive everything, then have each person re-add what they'd genuinely start in the next few weeks. Overlap reveals what actually matters to the team; items only one person rescues are worth a quick conversation. Agree on a cap and an archive trigger together so the rules stick. Shared backlogs rot faster than solo ones precisely because no single person feels ownership of pruning — a team cap fixes that.

Declaring backlog bankruptcy feels reckless for about five minutes, and then it feels like setting down a backpack you forgot you were carrying. The fear — losing something important — turns out to be unfounded, because the good ideas come back and the archive holds the rest. What you actually lose is the noise, the guilt, and the daily reminder of everything undone. Archive the graveyard, rebuild something honest and small, cap it, and defend it. Your next decision just got a lot easier — which, in the end, is the only thing a backlog was ever for.