Ordering the Product Backlog: value, risk and dependencies

"Everything is top priority" is the most common sentence in backlog meetings, and the most useless. If everything comes first, nothing does, and the team ends up choosing by default: the easiest item, the loudest requester, or whatever it has already started. Ordering is how a Product Owner stops that from happening.

What Scrum requires

Very little, on purpose. The Scrum Guide makes ordering Product Backlog items one of the four things the Product Owner is accountable for, and says the Product Backlog is an ordered list. It does not say how to order it. Attributes of items "often vary with the domain of work", and the Product Owner may influence the Developers by helping them understand and select trade-offs, but the method is left open.

Two things are fixed. First, one person decides: the Product Owner is one person, not a committee, and those who want to change the order do so by convincing them. Second, the order must be visible. The Product Owner's decisions are seen in the content and ordering of the Product Backlog and in the Increment.

Three factors worth weighing

The SBOK® Guide gives the clearest practical frame. When ordering the Prioritized Product Backlog, the Product Owner considers three factors: value, risk or uncertainty, and dependencies. It is a useful frame whether or not you use the SBOK.

Value

What does the item deliver, and to whom? The SBOK says the Product Owner should ensure that the highest business value is delivered first, and that even a very valuable item may not make the first release if others of higher value are enough for it. Value can be estimated subjectively or based on analysis using customer interviews, surveys and financial models.

Be specific. "High value" is not an estimate. Revenue, cost avoided, risk reduced, time saved, a legal requirement, or learning gained are all forms of value, and they are not directly comparable. Stating which kind you mean makes the argument easier.

Risk and uncertainty

The more uncertainty an item carries, the earlier it deserves attention. The SBOK says riskier items should be given higher priority, because dealing with risk early does not guarantee success but improves the team's ability to cope. Doing a risky item first means finding out, while the budget is intact, whether it can be done.

That produces an ordering that surprises people. A high-risk item of moderate value can rightly sit above a safe item of slightly higher value, because the information gained from the first changes everything planned after it.

Dependencies

Some items cannot start until another is finished. The SBOK points out that the Scrum Team alerts the Product Owner to dependencies that arise out of implementation, and that these must be considered in ordering. An item that unblocks several others is worth more than its own value suggests. An item that depends on something outside the team is a risk to schedule.

A worked example

This is an invented backlog for a small booking service, to show the reasoning.

A pure value ranking puts find, book and pay first. Adding risk changes one thing: payment is high-risk, so there is a case for starting on it early, perhaps using a test account, even though booking has to come first. Dependencies fix the chain: find, then book, then pay, then cancel. The profile page has no dependencies and moderate value, so it can fill space. Reminders are cheap but low in value and wait.

A reasonable order is therefore: find a tutor, book a lesson, pay for a lesson (with the provider integration started in the same Sprint as booking), tutor profile, cancel and refund, reminders. Someone else might defend a different order, and that is fine, so long as the reasons are stated. A backlog that records why an item sits where it does saves many future arguments.

Techniques for reaching an order

The SBOK lists several, and all are aids for the Product Owner rather than rules.

• MoSCoW. Items are labelled Must have, Should have, Could have or Won't have. A Must have is something without which the product has no value. The scheme is better than a simple high, medium, low scale because "Won't have" forces a decision to exclude. Its weakness is that stakeholders label everything "Must".
• Paired comparison. List the items, then compare each against each other, asking only which of the two is more important. Tallying the results produces an order. It works well for short lists and becomes tedious as the list grows, because the number of comparisons rises quickly.
• 100-point method. Give each participant 100 points to distribute across the items. Totals give the order. It makes stakeholders face a budget: if they put 60 on one item, that leaves 40 for everything else.
• Kano analysis. The SBOK describes a model that sorts features into four groups by customer preference: delighters, satisfiers, dissatisfiers (features whose absence makes customers dislike the product) and indifferent features that should be dropped. It helps when deciding between basic needs and extras.

None of these gives an answer by itself. They collect opinions in a structured way, and the Product Owner makes the final call.

Common mistakes

• Ordering by who asked. The loudest or most senior requester is not a measure of value.
• Ordering by effort. Easy items rise to the top because they are easy. Effort matters for sequencing, but it is a different question from value.
• Ignoring risk. A backlog ordered by value alone leaves the dangerous items to the end, where discovering they are impossible is expensive.
• Never reordering. The order should reflect what the team has learned. A backlog that has not changed after a Sprint Review is probably not being used.
• Treating the top as a commitment. The order says what is next, not what is certain. Items move.
• A hidden rationale. If the Product Owner cannot explain why an item is where it is, stakeholders will fill the gap with theories.

The Agile Manifesto's first principle is to satisfy the customer through early and continuous delivery of valuable software. Ordering is the daily mechanism for that.

How to practise it

Ordering looks easy until two items are both urgent and one of them has a dependency. In the simulator, the backlog is ranked by value and risk at step 1.5, and the quality of that ranking affects the rest of the project.