Growing Backlog: The In/Out Rule

The growing backlog: three unmistakable symptoms

You open your board on Monday morning and the first column has 400 cards. You scroll. You close it. You add one more. That's the sign that your backlog is no longer a prioritization tool, but a journal.

Three symptoms keep coming back:

• The planning ritual that drags on. Every sprint, you go through the list again, argue, and choose based on who spoke the loudest that week.
• Old items that never die. An idea submitted eight months ago stays "pending" without anyone knowing why.
• Absurd comparisons. You put "migrate authentication" next to "change the onboarding button color" as if they were the same type of decision.

These three symptoms come from the same structural cause: a flat backlog. When everything is at the same level, every priority conversation starts from scratch.

Separate the altitudes before measuring anything

The flight levels model describes three decision altitudes: strategic (where to invest), coordination (how work flows between teams), and operational (how a team executes). Each altitude has its own rhythm, decision-makers, and definition of "done."

When an organization manages everything at a single altitude, strategic decisions get drowned in operational debates, and tactical adjustments take on the same solemnity as a platform bet. Nothing moves at the right pace.

Concretely, before counting entries and exits, sort things out:

• Strategic: "Should we replace our payment system?" — quarterly decision, few people in the room.
• Coordination: "Which initiative addresses which customer problem this quarter?" — monthly review.
• Operational: "Which user story goes into this sprint?" — weekly team decision.

An item that doesn't belong to the altitude of the current meeting has no business there. This simple filter eliminates half of the sterile debates.

Why a saturated backlog slows down exponentially

Queueing theory applied to product development gives a counterintuitive result: when a resource approaches 100% utilization, the queue grows exponentially, not linearly. The M/M/1 formula is written as wait = utilization / (1 − utilization). At 50% utilization, the wait is 1×. At 80%, 4×. At 90%, 9×. At 95%, 19×.

In other words: the more you tighten your capacity, the more the queue explodes. You won't catch up with an exponential by working more.

Little's law gives the other half of the picture: cycle time = work in progress / throughput. A documented open source project had about 200 open pull requests and merged 20 to 35 PRs per month: the average cycle time came out to about 6.7 months. That's not a temporary backlog, it's the normal behavior of the system at that load.

The same reasoning applies to your backlog: if you have 180 open items and you deliver 6 per sprint, your average traversal time is 30 sprints. That number, displayed in a meeting, often changes the conversation more effectively than a debate of opinions.

The in/out tracking table, in five columns

You don't need a sophisticated tool. A shared spreadsheet is enough, as long as you fill it in every week, at the same time, by the same person.

Five columns:

1. Week — the date of the reading.
2. Entries — number of items added to the backlog this week.
3. Delivered exits — items moved to "done" and actually usable.
4. Abandoned exits — items explicitly closed without being delivered.
5. Total open — the balance at the end of the week.

Two ratios calculate themselves:

• In/out ratio = entries ÷ (delivered + abandoned). Above 1, the backlog is growing. Below 1, it's shrinking.
• Median age of open items — half of the open items are older than this number of weeks. If it exceeds 12, your backlog is an archive, not a plan.

The number that triggers action is the in/out ratio over four consecutive weeks. If it stays above 1.2, you have a cap problem, not a productivity problem.

A platform like Ever Earlier displays an activity log per card and per column: you can reconstruct these numbers without keeping a parallel spreadsheet, by filtering cards created and completed over the period.

Set a cap per sprint (and stick to it)

An entry cap is not a limit on imagination. It's a limit on accepted work. The distinction is essential when you announce it.

Three simple rules:

• Entry cap: for example 5 new items per sprint per team. Beyond that, the item goes into a "to qualify" list that is not the active backlog.
• Mandatory exit threshold: any item open for more than 8 sprints is either scheduled in the next 2 sprints or closed. No gray area.
• Cleanup budget: 10 to 15% of sprint capacity reserved for grooming and closing obsolete items. That's not wasted time, it's what prevents the queue from exploding.

The cap must be visible. On a Kanban board, a "To qualify" column with a counter is enough. When it's full, you no longer discuss adding, you discuss what to remove.

Be careful not to confuse entry cap with work-in-progress cap. The first limits what enters the backlog; the second limits what is being executed. Both are useful, but they don't substitute for each other.

Saying no without conflict: four scripts to reuse

Most conflicts around the backlog don't come from a disagreement about the value of the idea, but from a misunderstanding of what "adding to the backlog" means. Reframe the conversation around cost, not merit.

Script 1 — When an executive adds an idea in a meeting

"I'm noting the idea, it's legitimate. To put it in the current sprint, we have to remove something else: here are the three items at the same priority level. Which one do we push back?"

You're not refusing. You're making the cost visible.

Script 2 — When a stakeholder insists on urgency

"Agreed on the urgency. Our entry cap for this sprint is reached. Two options: we handle it in the next sprint as high priority, or we push back item X that was planned. Which do you prefer?"

Script 3 — When an item has been sleeping for months

"This item has been open for six months without being planned. Is it still relevant? If so, we'll schedule it in the next two sprints. If not, we'll close it and keep a note for the history."

Script 4 — When you're criticized for "saying no to everything"

"We're not saying no to ideas, we're saying no to piling up. Every item we add without removing another lengthens the delivery time of all the others. Here's this week's number."

These four scripts work because they shift the decision: it's no longer "your idea versus mine," it's "which item goes out so this one can come in."

What about refactoring? It doesn't go in the backlog

Classic question: should you create refactoring user stories in the backlog? The answer, formulated long ago by Ron Jeffries, still holds: it's a bad idea.

A big cleanup project is hard to sell, and when it is sold, it delivers less than expected after a long delay. The right approach is incremental: when you build the next feature, instead of working around problematic areas, you clean the path you traverse. You ignore the code you don't have to touch.

Sometimes the feature takes a little longer. Often it doesn't, because the cleanup helps from the first feature that goes through there. And the next time, the benefit is immediate.

Practical consequence for your backlog: don't create generic "technical debt" items. Instead, add an acceptance criterion to the current user story, such as "module X is covered by tests before going to production." Cleanup becomes a property of the feature, not a separate project.

The weekly ritual: 30 minutes, five questions

A tracking table is useless if it isn't read. Block 30 minutes per week, outside the classic agile ceremonies, with the person who owns the backlog.

Five questions, in this order:

1. How many items came in this week? From whom?
2. How many went out, delivered or abandoned?
3. What is the in/out ratio over the last four weeks?
4. Which open items are more than 8 sprints old? What are we doing with them?
5. Is the entry cap for the next sprint already reached?

If the answer to question 5 is yes, the next planning meeting starts with a removal decision, not an addition. That's what distinguishes a living backlog from a graveyard with a search bar.

On Ever Earlier, you can filter cards by creation date and status in the activity log, then export the view for the meeting. The AI agent that generates user stories from epics remains useful, as long as you don't use it to fill the backlog faster than you empty it.