← All articles

When the Backlog Lied: A Hardware Team's Lesson in Ordering by Value

By XNM Technologies · September 23, 2021 · 3 min read
When the Backlog Lied: A Hardware Team's Lesson in Ordering by Value

In the spring of 2021, a product team I'll call the Northgate group was rebuilding momentum after a rough year. Half the team was remote, a key supplier was still quoting twelve-week lead times on a control board, and the product owner had a backlog with 140 items in it. On paper they were doing Scrum. In practice, the order of that backlog was an accident of history: whoever had filed a request most recently, or argued most forcefully in the last review, ended up near the top.

The Scrum Guide is blunt on this point. The Product Backlog is an ordered list, and the Product Owner is accountable for that ordering. Ordered does not mean sorted by date, by effort, or by who is loudest. It means sequenced so the work most likely to deliver value comes first. Northgate had skipped that discipline, and it was costing them sprints.

How the disorder showed up

The symptoms were familiar. Sprints finished with a pile of 'done' items that no customer had asked for, while a feature three sales deals were waiting on sat at position 47. The team kept context-switching because the top of the backlog had no coherent theme. And because the supply-disrupted control board blocked one hardware path, anything depending on it should have dropped down the list — but nobody had moved it, so the team kept tripping over half-startable work.

When we sat down with the product owner, the real issue surfaced fast. She was ordering by request, not by value. Every stakeholder ask went onto the pile in roughly the order it arrived, and 'priority' was a label people attached to their own items, not a property of the list as a whole.

Reordering by value, deliberately

We did not introduce a heavyweight scoring framework. The team needed something they could run every refinement session without a spreadsheet ceremony. The questions we used to compare any two backlog items were simple and concrete:

  1. What value does this unlock, and for whom? A revenue commitment, a regulatory deadline, a fix that stops customers leaving — these outrank a tidy internal refactor, however satisfying.

  2. What does it cost us to wait? Some items get cheaper or more urgent over time. The supply-disrupted board work got more expensive to delay because lead times kept slipping; the nice-to-have report did not.

  3. Is it actually doable now? An item blocked by a missing part or an absent decision cannot sit at the top, no matter how valuable. Order reflects readiness as well as worth.

  4. Does it reduce risk or uncertainty? Pulling a risky integration forward, even before its glamorous features, often delivers more real value than another safe increment.

The product owner kept the accountability — ordering is hers to own — but she now made it transparent. The top ten items had a one-line rationale each, visible to the whole team and to stakeholders. That single change ended most of the hallway lobbying, because a request to jump the queue now had to argue against a stated reason, not against silence.

What changed after two sprints

  • The sales-blocking feature shipped in the next sprint instead of drifting; the backlog finally reflected what the business actually needed.

  • Supply-blocked work moved down and stopped fragmenting sprints, so the team held a coherent theme each cycle.

  • Refinement got faster, because comparing items by value is quicker than relitigating who asked first.

  • Stakeholders trusted the order more, precisely because they could see the reasoning behind it.

None of this is exotic. It is the ordinary discipline the Scrum framework already asks for, applied honestly. A backlog is not a to-do list in arrival order; it is a living statement of what matters most, next. When a remote, supply-constrained team gets that statement right, every other Scrum event works better — because the team is finally pulling from the top of a list that means something.

If your delivery teams are busy but the order of work no longer reflects value, XNM's program & project delivery advisory can help you put real prioritization back at the centre of how you deliver.