Prioritising a Backlog With AI: What to Automate and What to Decide

A backlog is cheap to fill and expensive to order. With AI assistants the filling is almost free: ask for ideas and you can have forty in a minute. The ordering has not got easier. This guide separates the backlog work an assistant does well from the parts that are yours, works through three scoring methods (RICE, cost of delay and WSJF) with made-up inputs so you can check every figure, and ends with how to show the order when an assumption changes.

For the step before this one, deciding what outcome the work is meant to move, see our guide to outcome-based product ownership.

1. Who owns the order

The Scrum Guide 2020 describes the Product Backlog as an emergent, ordered list of what is needed to improve the product. It makes the Product Owner accountable for effective backlog management, which includes ordering the items, and it adds that the Product Owner may do this work or delegate it. The same guide says the Product Owner is one person, not a committee, and that the people doing the work are responsible for the sizing.

Two consequences follow for anyone using AI.

• You can delegate the work, but not the accountability. If you adopt an assistant's order unread, the answer to "why is this first?" becomes "the tool said so", which is not an answer.
• Effort and size come from the people who will build it, not from you and not from a model. An assistant can ask for those figures, tabulate them and flag items without one. It should not invent them.

2. What an AI assistant does well

Think of the assistant as a fast clerk, fluent with text and numbers, who knows nothing about your customers or constraints. Used that way, it earns its place.

Two habits keep this safe. Give the assistant only data you are permitted to share (see our guide on using AI safely at work). And check the arithmetic: have a spreadsheet or script do the sums rather than trusting the model's mental arithmetic. A fluent table of wrong numbers looks exactly like a table of right ones.

3. What only the product owner decides

Four decisions do not delegate.

1. The value assumptions. What counts as value, for whom, and how much. Is a minute saved for an internal agent worth the same as a minute saved for a customer? Those are choices about what the product is for, and a model has no stake in them.
2. The order. Scores inform it. Dependencies, commitments, capacity and risk also shape it. You decide and you explain.
3. The trade-offs. Doing the small, certain thing now means not doing the large, uncertain one yet. State each such choice, with what you give up.
4. Saying no. Every item you drop or defer has someone who wanted it. A refusal needs a readable reason and a way back in if the evidence changes. An assistant can draft the polite wording, but it cannot decide the refusal should be made.

The senior person's view, the latest complaint and the expert's prediction all carry information, and none of them is an order. A method chosen before you see which item it favours protects you from being steered.

4. Prune before you score

A backlog generated by AI is longer than a human one, and not always better. Scoring forty items is wasted effort if twenty should not be there. So prune first. For each item make one decision: keep, merge (with its twin) or drop, and write the reason.

Five reasons to drop or merge cover most cases.

• Duplicate. The same need in different words. Merge into one item with the clearest wording.
• Solution-led. The item names a thing to build ("add a chatbot") with no need behind it. Ask what the customer is trying to do. If you can state the need with evidence, rewrite the item around it. If you cannot, it is the next category.
• Unevidenced. Nothing shows the need is real: no interview, no data, no log. An assistant can produce a plausible need on demand, and a plausible need is not evidence. Find evidence, or park the item.
• Out of scope. It belongs to a different product, a later phase or another team's goal. Keep it in a parking list with the reason.
• Unsafe. It would let an AI make a decision that affects a person without a human accountable for it, or collect personal data without a clear purpose, or otherwise breach your organisation's rules. These do not go to scoring at all. Send them to whoever owns the risk.

1. 1CollectGather the AI-generated items with their stated sources
2. 2MergeCombine duplicates into one clearly worded item
3. 3TestCheck each for need, evidence, scope and safety
4. 4DecideKeep, merge or drop, with the reason written down
5. 5ScoreApply a method only to what survives

Keep the dropped list: it is where you look when a stakeholder asks why something is missing.

5. RICE: reach, impact, confidence, effort

RICE is a scoring method that Intercom published. Four inputs go into one number:

RICE score = Reach × Impact × Confidence ÷ Effort

• Reach: how many people or events the item affects in a defined period, such as customers per quarter. Intercom recommends using real product data in place of guesses.
• Impact: the effect on each person reached, chosen from a fixed scale. In Intercom's version: 3 for massive, 2 for high, 1 for medium, 0.5 for low and 0.25 for minimal.
• Confidence: how sure you are of the other estimates, as a percentage. Intercom's levels are 100% for high, 80% for medium and 50% for low, and it calls anything below 50% a moonshot.
• Effort: the work needed from product, design and engineering, in person-months in Intercom's version. Effort divides the total, so a cheaper item scores higher.

A worked example with made-up inputs. The numbers below are invented for the arithmetic and describe no real product. Three candidate items, scored by the formula:

• A: onboarding checklist1600
• B: bulk export1500
• C: AI reply suggestions600

The order is A, B, C, but A and B are close, so look at what A rests on.

• If A's effort is re-estimated from 2 to 3 person-months, its score becomes 4000 × 1 × 0.8 ÷ 3 = 1066.67, and B moves ahead.
• If A's confidence falls from 80% to 50% because the only evidence turns out to be one conversation, its score is 4000 × 1 × 0.5 ÷ 2 = 1000, and B moves ahead.
• The break-even for A's effort is 4000 × 1 × 0.8 ÷ 1500 = 2.13 person-months. Above that, B leads. The break-even for A's confidence is 1500 × 2 ÷ 4000 = 75%. Below that, B leads.

• A: onboarding checklist1066.67
• B: bulk export1500
• C: AI reply suggestions600

The useful output is not "A is best" but "A is first only while its effort stays under 2.13 and its confidence above 75%". Those are the two things to firm up.

Where RICE misleads.

• The impact scale is a rank, not a measurement. A 2 is not exactly twice a 1, so treat small score differences as ties.
• Confidence is easy to type and hard to justify. Tie each level to evidence you can name. An opinion, a vendor brochure or an AI suggestion is not evidence for high confidence.
• It ignores time. An item worth the same every week and an item whose value disappears after a date can have the same score.
• Reach must be the right population. An item for one segment should use that segment's volume, over the same period as every other item.
• Intercom itself says scores are not a hard and fast rule. Dependencies can put a lower-scoring item first.

6. Cost of delay and CD3

Cost of delay is the value lost for every unit of time that an item is not live. The Black Swan Farming site, which presents Don Reinertsen's work, describes it as a way of communicating the impact of time on the outcomes we hope to achieve, and says it combines urgency and value. Two items of equal total value can have very different costs of delay if one loses its value after a date.

The practical rule that follows is CD3, cost of delay divided by duration: do first the item that loses the most value per week of work it needs.

A worked example with made-up inputs. One team does two items in sequence. Item P loses ₹50,000 of value for each week it is not live and takes 4 weeks. Item Q loses ₹1,20,000 a week and takes 10 weeks.

• CD3 for P = 50,000 ÷ 4 = 12,500 a week of work. CD3 for Q = 1,20,000 ÷ 10 = 12,000. P goes first.
• P first: P is live in week 4, costing 4 × 50,000 = ₹2,00,000. Q is live in week 14, costing 14 × 1,20,000 = ₹16,80,000. The total waiting cost is ₹18,80,000.
• Q first: Q is live in week 10, costing 10 × 1,20,000 = ₹12,00,000. P is live in week 14, costing 14 × 50,000 = ₹7,00,000. The total is ₹19,00,000.

• ₹18,80,000if P is done first
• ₹19,00,000if Q is done first
• ₹20,000saved by choosing P first

The order matters here, but only by ₹20,000 on a total of about ₹19,00,000, because the two CD3 values are close. When ratios are that near, other things (risk, a dependency, learning) should decide. When they are far apart, the order matters a great deal.

Where cost of delay misleads. It needs a value you can defend for each week of delay, and many items resist that. It assumes one team working in sequence and a roughly constant weekly cost. If value collapses after a deadline, a constant figure misstates the cost, and the better move is to schedule to the date. Keep customer value and company value on separate lines, so the choice of whose money you count is visible.

7. WSJF: weighted shortest job first

WSJF (weighted shortest job first) is the prioritisation method in the Scaled Agile Framework (SAFe), built on cost of delay. Scaled Agile gives it as cost of delay divided by job duration, with job size used as a proxy for duration because duration is hard to know early. SAFe builds cost of delay from three parts, scored relatively rather than in money:

• User and business value: user preference, revenue impact and any penalty for delay.
• Time criticality: how fast the value decays, and whether there is a fixed deadline.
• Risk reduction and opportunity enablement: whether the work reduces risk, gives useful information or opens new opportunities.

WSJF = (user-business value + time criticality + risk reduction or opportunity enablement) ÷ job size

SAFe's guidance is to score one column at a time, giving the smallest item in it a 1 and rating the others against it, using a modified Fibonacci series (1, 2, 3, 5, 8, 13, 20) as in planning poker. It warns that size is a weak proxy for duration when you can add people.

A worked example with made-up scores.

• Y4.67
• X2.6
• Z1.54

By cost of delay alone the order is Z, Y, X. By WSJF it is Y, X, Z: the large item Z has the highest cost of delay but takes so long that it should not block smaller ones. Now suppose Y's time criticality was driven by a date that has passed, so it drops from 8 to 1. Y's cost of delay becomes 5 + 1 + 1 = 7, and its WSJF is 7 ÷ 3 = 2.33. Now X (2.6) is ahead of Y.

Where WSJF misleads.

• Relative scores feel exact but are not. An 8 against a 5 is a group judgement, and groups anchor on whoever speaks first. Ask people to score separately, then compare.
• Summing three scales treats them as equal. Whether time criticality deserves the same weight as value is itself a value assumption, and it is yours.
• Job size is a proxy. A job that looks small but depends on another team is slower than its size suggests.
• It is easy to reverse-engineer. If someone wants an item first, they can tune its three components, so decide what each score means before you score.

Mixing methods is a further trap: a list where some items have RICE scores and others WSJF cannot be sorted, because the units differ. RICE suits many items early on, when you can count who is affected and grade your evidence but cannot price the effect. Cost of delay or WSJF suits items that one team will build in sequence and whose value you can price or score. A prerequisite that other items cannot go live without is sequenced first and not scored at all.

8. Showing the order under changed assumptions

Every score rests on assumptions, such as a volume, an effect, a size or a view of what counts as value, and some will change. Sensitivity analysis means changing one assumption at a time, recomputing, and seeing what moves.

1. Name the assumption with its old and new values and where each came from.
2. Find every item that uses it. A unit cost might sit in four items; a size sits in one.
3. Recompute only those items, re-order and list which moved.
4. Find the break-even, the value at which two items swap, as in the RICE example above.

When you present the result, say four things in this order: what changed and its source, what it did to the order, what did not change, and who decides and when you will look again. For example: "Item A's effort estimate went from 2 to 3 person-months, per the engineering lead. A and B swap. C stays last. The first two weeks of work are unaffected. I will confirm the order once the estimate is firm."

Do not hide a change because the new order is awkward, and do not reorder for every rumour: a change you cannot source is an open question, not a new assumption. An assistant can recompute the table under each scenario in seconds, but you choose the scenarios and own the explanation.

9. A short exercise

Take ten items from your own backlog. Mark each keep, merge or drop with a reason. Choose a method before you see the results and write down why it fits. Write the source next to every input, and mark any input that is only an opinion. Compute the scores in a spreadsheet and recompute two by hand. Change your least certain input and note whether the order moves. Finally, write the order, the trade-off you accepted and the item you said no to.

10. How our course practises this

Weeks 4 and 5 of our AI-Enabled Product Ownership course cover pruning an AI-generated backlog and prioritising with RICE, cost of delay and WSJF, including finding errors in an AI-scored list and recomputing the order when an assumption changes. The platform grades every exercise on data dealt to you.

Sources and further reading

• Schwaber, K. and Sutherland, J. (2020), The Scrum Guide
• Intercom, RICE: Simple prioritization for product managers
• Scaled Agile, Inc., Weighted Shortest Job First
• Scaled Agile, Inc. (2016 archived copy of the WSJF article), Weighted Shortest Job First
• Black Swan Farming, Cost of Delay