Your Backlog Is Bad Because Your Org Chart Is

Pick five items from your Product Backlog at random. For each one, ask three questions:

1. Would a customer pay for this?
2. Can you demo it in Sprint Review?
3. Does it touch all system layers, end to end?

If most of your items fail even one of these, you don't have a writing problem. You have a structural problem.

The three V's

A good backlog item is Valuable (a customer would pay for it), Visible (an external observer can see the result), and Vertical (it slices through all system layers as a complete behavior).

Most teams I work with fail with Vertical. Not because they don’t understand it, but because their system makes it expensive. Their backlogs are full of items like "Build the API," "Design the database schema," or "Create the form." Each item touches one layer. None delivers a working behavior. None can be demoed. None can be shipped.

The usual response is to train people to write better stories. Run a story-splitting workshop. Distribute the INVEST checklist. I've done all three. They work for about two Sprints, then the backlogs drift back to horizontal, because nobody's writing skill was ever the problem.

The backlog mirrors the org chart

Melvin Conway observed in 1967 that organizations produce designs that mirror their communication structures. Backlogs are no exception.

When your teams are organized by technical component (Database Team, Frontend Team, API Team), the backlog decomposes into component-shaped work. The Database Team can only take database items. The Frontend Team can only take frontend items. So the Product Owner writes items that fit the teams. Not out of ignorance. Most POs I've worked with can describe a perfect vertical slice. They just can't give it to any single team. One customer need, say "filter products by price," becomes three items in three queues. A one-week feature becomes a six-week delivery.

I saw this at a 400-person software company. Before the redesign, their backlog read like an architecture diagram: "Implement caching layer." "Update REST endpoints." "Modify DB schema." Every item named a component. None named a customer. When we reorganized into cross-functional feature teams, the first Sprint was a mess. People who'd never worked together fumbled through problems they used to throw over the wall. I wondered if we'd moved too fast. Three weeks later, a Product Owner pulled up the board at Sprint Review and paused. "I can actually read this now." Nobody had run a workshop. Nobody had retrained anyone. The structure did the teaching faster than I ever could have.

Can component teams occasionally deliver vertical items? Yes, through heroic cross-team coordination. But heroism is not a system. You can run every story-splitting workshop in existence, and the Database Team will still routinely take only database work. When your backlog consistently fails the Vertical test, the problem is not the words on the cards. The problem is the boxes on the org chart.

The visibility test

The second V, Visible, is the most uncomfortable one.

Component teams demo API endpoints and database migrations. Technically impressive. Entirely invisible to anyone who cares about the product. The test: what can the user actually do after this Sprint that they couldn't do before?

Component teams can't answer this question consistently. They deliver fragments. The complete behavior shows up only after integration, which happens later, in a different Sprint, coordinated by someone else. Craig Larman calls this "fake done": local metrics show high velocity, Sprint commitments are met, code quality looks good within each component. But nothing ships. The system reports motion and delivers none. Everyone leaves Sprint Review feeling productive. That's the worst part.

The value trap

Valuable feels like safe ground. Your Product Owner talks to customers. Your prioritization framework exists. Surely what gets built is a product decision, not a structural one.

Sounds right. Now pull up last quarter's delivery. How much of it traced directly to the highest-value customer need at the time?

I've seen this in every component-team organization I've worked with: features get selected by what available teams can do quickest, not what customers need most. Larman documents the same pattern at scale: a component team assigned to build their part of a low-priority feature that wasn't due for over a year, "simply because it was easier to plan that way." The highest-value work sat waiting because no single team could deliver it end to end. The backlog filled with what was structurally convenient, which then gets rationalized as prioritization.

That's the trap. You think you're choosing what to build. The org chart already chose for you.

The honest limitation

Not every backlog item hits all three V's easily. But the common "exceptions" are less exceptional than they seem. Spikes aren't backlog items at all; they're team-level experiments done within a Sprint to reduce uncertainty on a real item. Infrastructure work is almost always customer-facing when framed honestly. The real exceptions are small.

The Three V's are a filter for most work. When the majority of your backlog fails the test, the exception is not the problem. The structure is.

What you can do

You probably can't redesign the org chart tomorrow. But you can stop pretending the backlog is the problem.

The next time "Build the API" shows up in the backlog, refuse it. Ask: what can the customer do with just the API? If the answer is nothing, it's not a backlog item. It's a task in disguise. That refusal will start an argument about why vertical items are impossible. Good. That's the conversation you need.

If you want evidence before the argument, run one experiment. One customer-facing feature. The people who normally hand it off to each other, delivering together in one Sprint. You won't need a second experiment.

Most people would rather run another workshop.