Does your backlog know what winning looks like?
The team is shipping. The sprint is healthy. Velocity is up. And the results are flat.
This is one of the harder problems to name, because nothing’s obviously broken. The team isn’t slow. The roadmap exists. The quarterly plans get made. And yet at the end of the quarter, it’s hard to point to a commercial outcome and say the delivery caused it.
The backlog is usually where to look.
“Jamie, I’ve spent £1m on an agency in the last 12 months, we’ve had a lot delivered, and I couldn’t tell you what has changed.”
That was a prospect, about a year ago. The agency had been delivering. The backlog had been moving. Nothing was obviously broken. And yet here was the person holding the budget saying they had no idea what they’d bought.
The answer: they’d been getting exactly what they’d asked that agency for.
The completion trap
A backlog is designed to be cleared. That’s what it’s for. Tickets go in, tickets come out. It’s an excellent system for tracking work. It’s a poor system for tracking whether the work matters.
The problem is that “done” and “moved the needle” are two different things, and teams that don’t make that distinction explicit will routinely hit the first without the second.
Every backlog item made sense when it was raised. Someone added it because it seemed worth doing. But the connection between “worth doing” and “contributes to this year’s goals” often goes unstated – and once enough time passes, unstated becomes invisible.
The reflex when results are flat is to add more tickets. Better monitoring. Another integration. Refresh the PDPs, improve the navigation, add a feature a competitor shipped last quarter. Each defensible on its own. Collectively, they extend the backlog while the outcome stays where it was.
More things doesn’t mean more results.
The laddering question
The personal version of this question – does this serve my North Star? – is a useful filter for individual prioritisation. At team level, the same question applies to every item in the backlog: which specific goal does this serve, and how will we know if it worked?
If you can’t answer that before the ticket enters the sprint, it’s doing calendar work, not commercial work. It fills time with effort that looks productive and might even be good work – it just doesn’t reliably move anything that matters.
Feature lists don’t become roadmaps until you know what “better” looks like – and the same logic runs downward from the roadmap into the backlog. The roadmap sets the direction. The backlog is how the team moves in that direction. When the two aren’t connected, the team is moving. Just not necessarily forward.
The laddering question creates the connection. It forces a decision at the point of prioritisation: not “is this a good idea?” but “is this the best way to make progress toward the outcome we said matters this quarter?”
The agreement that has to happen first
Here’s where most teams stall. Answering “which goal does this serve?” depends on which goals the team is actually working from – and in most ecommerce operations, that’s not as agreed as it looks.
The commercial team has one view of what matters this quarter. The delivery lead has another. The Head of Ecommerce is managing upward against a third set of expectations. Nobody set out to create three competing definitions of success, but nobody built a process to bring them together either.
Defining what success looks like before the work starts is harder than it sounds, because it requires everyone with a stake in the outcome to agree on which two or three commercial metrics actually matter this year – before prioritisation happens, not after the sprint is already full.
When that agreement exists, the backlog gets a filter. Items get connected to outcomes. Sprint planning becomes a commercial conversation first, a delivery conversation second. The team can look at the queue and say: “these tickets are pointed at the thing we agreed to move; these aren’t, and they’re going in the parking lot.”
The teams that do this well aren’t more disciplined by nature. They’ve written the agreement down and let it do the work.
What this changes
Try this. Take the last six months of completed work from your backlog and sort it into three columns: work that moved a commercial metric, experiments that tested a hypothesis, and work that served the internal team or kept the lights on. The ratio tells you something. Most teams find the third column is larger than expected and the first significantly smaller. That’s not a failure of execution. It’s information about what the backlog was actually optimised for.
It’s uncomfortable to hold 80% of a backlog up to the question “does this ladder to our goals?” and find that a lot of it doesn’t. That doesn’t mean the work was wasted. It means the system for deciding what goes in wasn’t doing its job.
The clarity that follows is worth it. Trade-off decisions get faster. Scope conversations have a frame. The quarterly review stops being “we shipped a lot, results are mixed” and starts being “we shipped the things that were pointed at the outcomes we agreed on, and here’s what moved.”
The backlog is a tool. It does what it’s designed to do, which is track and sequence work. What it can’t do is decide which work matters. That’s the roadmap’s job – and behind the roadmap is the agreement about what winning looks like.
Get that agreement right, and the backlog becomes something different. Not a list of things to do. A list of things that count.