I've stepped into a few engagements where the team pointed me to their backlog and I found something closer to a warehouse. Hundreds of items. Some of them a couple of years old. Vague titles. No ACs. No clear priority. Nobody could tell me which items still mattered or why.
Technically, yes, it was a backlog. Practically, it wasn't doing the team much good.
A backlog is supposed to be a living picture of the work that matters most. The team should be able to look at the top of it and know exactly what's coming next and why. Getting it to that point, and keeping it there, takes consistent attention. Here's how I think about it.
ACs are where clarity actually lives
You can write a perfectly reasonable user story and still send a developer in the wrong direction if the ACs aren't clear. ACs are where the team gets specific: what does "done" look like for this item? What conditions does the work have to meet before anyone signs off?
Getting ACs right usually requires real conversation, not just documentation. The product owner might know what outcome they're after. But the developer asking "what happens if the user does X?" or "does this need to handle Y edge case?" is what turns a vague requirement into something actually buildable. Those conversations need to happen before sprint planning. Not during it.
Decomposition is its own skill
Large backlog items create problems mid-sprint. If the team pulls in something huge and it's only half-done at the end of the sprint, velocity gets blurry and forecasting becomes guesswork. Breaking work into smaller, independently deliverable chunks isn't just an Agile formality. It's how you maintain clarity on what's actually getting done.
This is often where your architect or lead developer earns their keep in the refinement process. They're the right person to look at a large PBI and figure out how to break it into bite-size work. You don't need the whole team in the room for that step. But you do need the whole team to review and commit at sprint planning, and that only goes smoothly if the decomposition work already happened.
Sprint planning should be the easy part
If people are reading stories for the first time at sprint planning and asking basic questions about what they mean, something went wrong upstream. Planning turns into refinement, refinement bleeds into the sprint, and the team starts the work already a step behind.
All that upstream work, the conversations, the decomposition, the ACs, exists to make sprint planning feel almost routine. The team looks at what's ready, pulls in what they can confidently commit to, and gets to work.
Don't forget the bottom of the backlog
Things change. A feature that felt urgent six months ago might not matter anymore. I make a habit of encouraging teams to periodically look at older items and be honest about whether they still belong. Pruning a backlog is not failure. It's just maintenance.
A healthy backlog doesn't stay healthy on its own. It's something you tend to, sprint by sprint.
When was the last time your team actually pruned old items out of the backlog? And what's sitting at the top of your backlog right now that might need clearer ACs before anyone pulls it into a sprint?