Dependencies Are Invisible in a Backlog

Sprint planning ends. The team picks their tickets. Everyone has work to do.

Three days in, someone opens a ticket and realises they can’t start it. The API it depends on hasn’t been built yet. The team that owns that API thought it was scheduled for next sprint. Nobody flagged the dependency in the backlog because in a backlog, there is nowhere to put it.

This happens constantly. Not because teams are careless — because backlogs are structurally blind to dependencies.

What a backlog actually shows you

A backlog shows you a ranked list of items. Each item has a title, a description, maybe a label and an estimate. What it cannot show you is the relationship between items — which things need to happen before other things can happen.

You can write “depends on #1234” in a ticket description. Most teams do. But that’s a text reference, not a visible connection. You have to know to look for it. The backlog doesn’t surface it during planning, doesn’t warn you when you sequence things incorrectly, and doesn’t update when the ticket it references slips by two weeks.

The dependency exists. The backlog just can’t see it.

The discovery problem

Hidden dependencies don’t hurt you when they’re hidden. They hurt you at the moment of discovery — which is almost always the worst possible time.

You discover them when you try to start a ticket and can’t. When the engineer asks “wait, does X need to exist first?” in the stand-up on day four. When you get to the end of the sprint and realise that three completed tickets are sitting idle because the thing they hand off to isn’t done yet.

By then, the sprint is already broken. You’re not preventing a problem — you’re doing damage control.

Why this is structural, not organisational

The tempting response is to blame the process: better grooming, more thorough tickets, a dependency column in your tracker. These help at the margins.

But the real issue is that a backlog is a one-dimensional format representing a multi-dimensional problem. Your product work isn’t a queue — it’s a graph. Feature B depends on Feature A. Feature D shares infrastructure with Feature C. The team building the auth layer is a dependency for four different squads.

You cannot represent a graph as a list without losing information. The information you lose is always the same: the connections.

What making dependencies visible actually looks like

Draw the work instead of listing it.

Put your planned features on a canvas. Draw an arrow from Feature A to Feature B if B depends on A. Do this for a single sprint’s worth of work and you’ll see something you’ve never seen in a backlog: the actual shape of the work.

Some cards will have many arrows pointing in. Those are your load-bearing items — the ones that block everything downstream. They need to be done first, staffed well, and treated as risks if they slip.

Some cards will be isolated — no incoming or outgoing dependencies. These are genuinely parallelisable. You can start them any time and cut them without consequence.

Some cards will form long chains. A chain is a sequential constraint — it tells you the minimum duration of that work regardless of how many people you assign to it.

None of this is visible in a backlog. All of it becomes obvious on a canvas.

The cost of finding out late

There’s a calculation worth doing. Think about the last time a hidden dependency derailed a sprint. How much engineer time was spent context-switching? How much planning time was spent replanning? What slipped as a result?

Now imagine you had seen that dependency three weeks earlier, during planning, when it would have taken five minutes to reorder two tickets.

The backlog didn’t show you. A canvas would have.

---

Dependencies aren’t a planning failure. They’re a format failure. The backlog was never designed to show them — and no amount of process improvement will change what the format can and can’t represent.

See the graph. Don’t pretend it’s a list.