What four hundred items costs you
Objecting to a large backlog on grounds of tidiness gets you nowhere, because the Product Owner is not untidy, they are avoiding a decision. Name the costs instead, and name them as things that are happening now.
The first cost is that ordering becomes impossible. Ranking four hundred items against each other is not work anybody can do properly, so in practice the top twenty get ordered and the rest sit in an undifferentiated mass, which means the backlog has stopped being an ordered list and has become a list with an ordered prefix. That matters because the whole mechanism by which a backlog does its job — the next most valuable thing is at the top — only functions if the ordering is real.
The second cost is that clarification work is spread across items that will never be built. Every hour spent clarifying acceptance criteria for something that gets deleted in a year is an hour not spent on the thing the team starts on Monday, and with four hundred items the ratio of wasted to useful clarification is severe.
The third is that the backlog stops being trusted, and once it is not trusted people route around it. Requests arrive by direct message, work appears mid-sprint that was never in the list, and the tracker becomes a place where things are recorded rather than a place where things are decided. That is the failure that is hardest to reverse, and it is usually well advanced by the time somebody counts the items.
The fourth is quieter: a five-year-old item is a false promise. Somebody raised it, it is still open, and they reasonably believe it is coming.
Delete, and be honest that archiving is avoidance
The move that works is deletion, and the objection is always the same — what if somebody asks. Answer it directly: if a request matters, it will be raised again, and re-raising it costs one conversation, whereas keeping it costs a fraction of every ordering decision from now until it is deleted anyway. If it is never raised again, deleting it was correct.
Moving four hundred items to an archive label feels safer and achieves very little, because the mass still exists and the decision has still not been made. The one legitimate use of an archive is as a transition: agree that anything untouched for a year goes to the archive automatically this week, that nothing will be reviewed there, and that in six months the archive itself is deleted. If nobody can face that, the honest reading is that the real problem is not the backlog.
A practical route through it that survives contact with a nervous Product Owner is to sort by age and decide in bulk rather than item by item, taking three questions to each cluster: is this consistent with what the product is now for, would we start it in the next two quarters, and would anybody notice if it vanished. Bulk decisions are the only ones that will actually get made, because a four-hundred-item review at one item a minute is nearly seven hours and it will not happen twice.
Derive the refinement depth rather than picking one
The reason refinement clarifies nothing is often that it is aimed at the wrong items, and the fix is arithmetic rather than facilitation.
Work out the depth from what the team actually completes. Suppose the team has finished about six items a week over the last quarter and runs two-week Sprints, so a Sprint consumes roughly twelve items. Holding one and a half to two Sprints of clarified work gives you eighteen to twenty-four items that need to be genuinely ready, and that is the population the team should spend its two hours on. Anything beyond that horizon can be a title and a sentence, because clarifying it now means clarifying it against assumptions that will have changed by the time it is started.
That gives you three tiers with different standards, and the useful part is that the standard drops sharply as you go down:
| Depth | What must be true | Effort spent |
|---|
| Next two Sprints, about twenty items | Small enough to finish, acceptance criteria agreed, dependencies known | Most of the working session |
| Next quarter, roughly ordered | Understood well enough to size relatively and to spot a dependency | A short pass, once |
| Beyond that | A title and one sentence of intent | None |
The corollary is worth saying out loud because it is counterintuitive: refining more items is not better. Detail written months before the work starts is detail written against a stale understanding, and it decays silently while looking authoritative. A backlog with two hundred fully specified items is in worse shape than one with twenty, because now somebody has to work out which of the two hundred specifications is still true.
Refinement that clarifies nothing is missing something specific
Before redesigning the session, find out why two hours produces no clarity, because the cause is usually one of four things and only one of them is about facilitation.
The commonest is that the person who can answer the question is not in the room. A team can discuss what the compliance rule means for an hour, but only somebody with the authority to decide can end it, and without them the session produces a longer discussion rather than a decision. The fix is to identify which questions are outstanding, take them away with an owner and a date, and bring the answers back — not to discuss it harder.
The second is that refinement is being used to write specifications rather than to reach shared understanding. If the output is a document and the developers are an audience, nobody is learning anything and the session is theatre. The output should be items the team believes it can start, and the test is whether a developer can say what they would do first.
The third is that the items are too large to clarify at all. A discussion about something that would take a month cannot converge, because the unknowns are structural rather than definitional. Splitting has to happen before clarifying, and a refinement session that never splits anything is a diagnostic in itself.
The fourth is that the top of the backlog keeps changing, so each week the team refines a different twenty items and none of them are ever started. That is a prioritisation failure showing up in a refinement session, and no amount of technique in the session will fix it.
Keep the ordering with the person accountable for it
None of this is a licence to reorder the backlog yourself. Ordering it is the Product Owner's accountability, and taking it over solves this month and guarantees the same conversation next year with you as the bottleneck. What you can legitimately do is make the consequences visible: show what a Sprint's worth of capacity is against the ask, show how many items have not moved in a year, show which requests are older than the strategy they were raised under. Those are facts about the list rather than opinions about priority, and they are what makes deletion feel like a decision rather than a loss.
Then put a mechanism in place so it does not regrow. A standing rule that the backlog has a maximum size forces a deletion every time something is added, which is the only thing that reliably works, because the alternative depends on somebody choosing to do housekeeping in a week where nobody is asking for it.
© 2026 Preptima. Originally published at preptima.com (opens in a new tab).