Owning the Backlog

Part nine of the product owner toolbox. We’ve gone from vision to small stories. They all end up in one place.

The product owner, and only the product owner, manages the product backlog. They’re responsible for keeping it current and they decide what gets built and what doesn’t. They make sure the customer’s perspective gets into the backlog and that the backlog stays focused on value. They also make sure it’s prioritised and up to date, and that the meetings and work needed for that actually happen.

An endless loop

Managing a backlog never stops as long as the product exists. It’s a loop of five activities:

1. Capture: collect every need and request stakeholders have for the product.
2. Prioritise: put the collected items in order of expected value.
3. Refine and estimate: bring the items at the top to the level of detail needed to build them. This happens with the team, and the team decides how much detail and context everyone needs to understand an item.
4. Plan and coordinate: keep the backlog current while the work is happening, ideally with a story map or a roadmap. Keep those up to date too.
5. Review: at regular intervals, compare the value you expected from the items you built with the value they actually delivered. Feed the difference back into the backlog. Sprint reviews with stakeholders are where this happens.

Step five is the one that gets skipped. Without it, the backlog is a list of things to do, not a list of bets you’re checking.

One list for everything

A backlog holds more than stories. There are four kinds of items:

• Bugs
• Enablers: technical or architectural work that later stories need
• Stories
• Technical debt

All four go into the same list and are ranked against each other. All of them are there because building them adds value to the product and therefore to the customer.

The usual alternative is a separate list for technical debt that the team keeps on the side. That list is never ranked against anything, so it never gets worked on, until the debt turns into an outage and jumps the queue by itself.

Pick a method, then stick to it

There are many ways to order a backlog by value:

• Value versus cost: the simplest. Plot both and start top left.
• Buy a feature: Luke Hohmann’s game. Stakeholders get a budget of play money and buy the features they want most.
• WSJF (weighted shortest job first): from Don Reinertsen’s work, made popular by SAFe. Cost of delay divided by job size.
• Kano model: Noriaki Kano’s distinction between basic needs, performance features and features that delight.

Which one is best depends on the context. What matters more is using one method consistently for every item. A backlog prioritised by WSJF on Monday and by whoever shouts loudest on Thursday isn’t prioritised.

Priority poker

The method I’d most like to see in management meetings is priority poker. It works like planning poker, but it estimates priority instead of effort.

Each participant gets a deck of cards with values that grow roughly like the Fibonacci sequence, for example 100, 200, 300, 500, 800, 1300, 2100 and 3400. One item is given its priority up front as a reference. Then, for each item:

1. Someone presents the item.
2. Everyone picks a card in secret, and all cards are revealed at the same time.
3. The people with the highest and the lowest card explain why.
4. Everyone picks again in secret, and the cards are revealed again.
5. The group agrees on a value.

The estimates are relative: each item is compared to the ones already ranked. A moderator keeps the timebox and keeps the discussion focused on solutions.

The value lies in the social part. The people in the room aren’t just affected by the decision, they take part in it. The highest and lowest cards bring hidden knowledge to the table: the team lead who knows that a feature is useless in practice, or the developer who knows that a small change unlocks three others. The result is a ranking everyone helped build and therefore carries.

That includes management. Managers play themselves, and they can’t send someone in their place. Run it regularly, so that changes in priorities show up in the backlog on time instead of becoming firefighting exercises. It also works across levels: the priorities of one level set the goals of the level below.

The leave tool, after release 1

Release 1 went out. Here’s what came in afterwards, after a round of priority poker with HR, two team leads and the team:

Item	Kind	Priority
Balance is wrong for requests across New Year	Bug	3400
Half days	Story	2100
Automated tests for the balance calculation	Technical debt	2100
Mark understaffed weeks	Story	1300
Sick leave	Story	800
Approval in team chat	Story	300

Two observations. The bug won because HR explained that it affects everyone in December. And the tests ended up at the same priority as half days because the developer explained that the New Year bug happened because nobody could safely change the balance calculation. No one would have ranked the tests that high on their own.

Next

The last part of the series covers the two checklists at either end of the sprint: the Definition of Ready and the Definition of Done.