Your Backlog Is Lying to You

I was coaching a PM who told me her team had "good velocity but bad outcomes." Sprint after sprint, they finished what they committed to. But the product wasn't getting better. Users weren't happier. Leadership was losing patience.

I asked to see the backlog. Within ten minutes, the problem was obvious. The backlog wasn't a plan. It was a graveyard with some living things in it.

The five signs

After auditing backlogs across 30+ organizations, the same patterns show up everywhere. Here's how to tell if yours is broken.

1. Nobody can explain what half the tickets mean.

When I audit a backlog, I pick ten random stories and ask the team what they mean. If more than two require someone to say "I think that was from when we..." or "you'd have to ask [person who left]," the backlog is lying. Stories that can't be understood without oral history aren't stories. They're artifacts of a conversation nobody wrote down.

2. The backlog only grows.

Healthy backlogs shrink. They shrink because someone regularly reviews what's there and removes what's no longer relevant. If your backlog has been growing for six months without a single item being deleted (not completed, deleted), it's accumulating, not curating. A backlog that only grows trains the team to ignore it.

3. Stories are scoped by what's easy, not what's valuable.

This one is subtle. The backlog looks clean. Stories are small. Acceptance criteria are specific. But when you look at the pattern, everything is scoped around what engineering can deliver in a sprint, not around what would make a difference for users. The backlog becomes a list of technical tasks wearing user-story costumes.

4. "Placeholder" tickets have been there longer than 30 days.

A placeholder is fine for two weeks. After that, it's not a placeholder. It's a ghost that haunts every planning session. Someone mentions it. Someone says "we should get to that." Nobody does. The placeholder slowly becomes part of the landscape, taking up mental space and sprint planning time without ever turning into real work.

5. Sprint planning is a negotiation.

When planning meetings feel adversarial (product pushing for more, engineering pushing back), the backlog is usually the root cause. Stories aren't clear enough for engineering to estimate confidently. Scope is ambiguous. Acceptance criteria are missing or vague. The negotiation isn't about capacity. It's about the cost of figuring out what each story actually means during the sprint.

Why this happens

The backlogs I see aren't broken because the teams are lazy. They're broken because nobody taught the team what a good story looks like.

Most PMs learn story writing by copying what they've seen. If the last PM used vague one-liners, the current PM writes vague one-liners. If the team uses Jira and the template has an empty "Description" field, the description stays empty. The tool doesn't enforce quality. The process doesn't either.

I've taught story writing to 150+ PMs and coached 50+ engineers on what "done" means before a line of code gets written. The gap is almost never effort. It's craft. And craft can be taught.

What "ready for dev" actually means

A story is ready for development when an engineer can pick it up, understand it completely, and start building without asking a clarifying question. That's the bar. Most backlogs fail it consistently.

Ready-for-dev means:

User context. Who is doing this and why? Not "As a user, I want..." boilerplate. Actual context about the person, the situation, and what they're trying to accomplish. An engineer who understands the user context makes better implementation decisions.

Acceptance criteria. What does "done" look like? Specific, testable conditions. Not "the feature works correctly." What does correctly mean? What should happen on the happy path? What about the edge case? If you can't write acceptance criteria, you haven't finished thinking about the problem.

Scope boundaries. What is explicitly not part of this story? This is the one most teams skip, and it's the one that causes the most scope creep. When the boundary isn't stated, engineers make reasonable assumptions that may not match what the PM intended.

The audit that resets the system

When I do a backlog audit, I start by categorizing everything: stale (older than 3 months with no activity), too big (can't be finished in a sprint), too vague (acceptance criteria missing or untestable), and ready (clear, scoped, actionable). Most teams find that fewer than 20% of their tickets are actually ready.

Then I rewrite the top-priority stories. Not all of them. The ones closest to development, the ones the team will pick up in the next 2-3 sprints. I focus there because the best way to teach story quality is to show the team what good looks like on stories they're about to build.

The last deliverable is a lightweight playbook: templates, examples, and a definition of "ready for dev" tailored to the team's tools and workflow. The goal is that the backlog stays healthy after I leave, not that it was temporarily clean while I was there.

The return on clean stories

Teams with clean backlogs don't just ship faster. They ship with less friction. Planning meetings get shorter because stories don't need re-explanation. Engineers estimate with more confidence because scope is clear. Sprint commitments stick because acceptance criteria mean everyone agrees on what "done" means before the sprint starts.

A clean backlog is the foundation of predictable delivery. Most teams are one good audit away from a healthier rhythm.