Prioritising the backlog when everything is urgent

Five “urgent” requests in one morning

This is an illustrative situation. You are the PO of an online tea shop app. On Monday morning, before sprint planning, five people send you five requests. Every one of them says “urgent”.

• Sales wants a discount code just for loyal customers, for the end-of-month promotion.
• Accounting reports that the payment gateway partner will stop supporting the old integration on the 30th.
• Customer support says many customers are calling because they never received the order confirmation email.
• The director has just looked at a competitor's app and wants the home page redesigned to look more modern.
• Marketing wants Zalo sign-in so new customers can register faster.

The team can finish two, at most three, of these in the next sprint. You have to choose. Just as important, you have to tell the other people why their request is not being done, in a way they can accept.

This article is not about handling a single request. That is covered in the article on feature requests. This one is about the moment when many requests compete for the same slot: which method to compare them with, how to separate real urgency from felt urgency, and how to show the trade-off so everyone can see it.

• Handling a feature request from a stakeholder

Why is backlog prioritisation hard for new POs?

The backlog is the ordered list of everything the team could do for the product. The Scrum Guide states that the Product Owner is accountable for ordering it, and that the PO is one person, not a committee. That sounds simple. In practice it is hard for a few reasons.

• Each person sees only their own part. Sales sees revenue, support sees calls, the director sees competitors. Nobody is wrong, but nobody except the PO sees all five requests at once.
• “Urgent” is used for everything. When everyone says urgent, the word stops meaning anything. You need another way to tell which work truly cannot wait.
• New POs rarely have positional authority. The requester may be your manager or someone with far more tenure. Without a clear reason, your decision is easy to overturn.
• Prioritising one item means pushing others back. The pushed-back part is rarely said out loud, so stakeholders only see “the PO is not doing my thing”.

So the goal is not a perfect order. The goal is an order that is reasonable, that you can explain in two minutes, and that tells people what they would need to bring to change it.

Value vs effort, MoSCoW or RICE: which should you use?

There are many prioritisation methods. For a new PO, these three are enough. They do not exclude each other. What matters is that each one answers a different question.

Value vs effort is the simplest. You rate each item on two axes, the value it brings and the effort it takes, and place it in one of four boxes. It is quick and easy to draw on a whiteboard in a meeting.

MoSCoW sorts work into Must have, Should have, Could have and Won't have (this time). According to ProductPlan, Dai Clegg created it while working at Oracle. Its strongest part is the Won't have group: it says up front what will not be included, so nobody is surprised at release. Its weakness is that it does not rank items inside each group, so you need another method when many items are all Musts.

RICE was introduced by Intercom. It stands for Reach (how many people are affected in a period), Impact (how much each person is affected, on a scale of 3, 2, 1, 0.5 and 0.25), Confidence (how sure you are of the estimates, typically 100%, 80% or 50%) and Effort (person-months of work). The score is Reach times Impact times Confidence, divided by Effort. Intercom itself says RICE scores should not be treated as a hard rule.

A practical way to choose: use value vs effort when you are new and have little data, MoSCoW when a release date needs a fixed scope, and RICE when the backlog is long and you want to compare many ideas with less guesswork. Whichever you pick, its biggest benefit is that it makes people state their assumptions.

How do you separate real urgency from felt urgency?

Before scoring anything, pull out the items with a real deadline. Do not score them against the rest, because the cost of missing the date does not appear in any formula.

Felt urgency is still real to the person feeling it. Support is tired of hearing complaints all day, and the director worries because a competitor looks better. You do not need to deny that feeling. You only need to stop it from automatically changing the whole team's plan. Instead, put the item in the scoring group and let its reasons be weighed against the reasons for everything else.

Steps to a backlog order you can explain

Put the pieces together and you have a four-step process. For five or ten requests, all of it fits in one afternoon.

In step 1, clarify each request until you can state the problem in one sentence. If you cannot, go back to the requester before scoring. Scoring a vague request only produces a vague number.

In step 3, engineers should estimate effort, not the PO. Value and reach should come from data when it exists: support call counts, monthly orders, how many customers use a related feature. When there is no data, write “estimate” and lower the confidence.

How do you make the trade-off visible to stakeholders?

Much of the tension about priorities comes from people not seeing the cost of a choice. When the director says “do the home page first”, it sounds like adding something. In reality it pushes something else out. The PO's job is to make that pushed-out item visible.

• Speak in pairs. Instead of “the team can't do it”, say “if we do the home page this sprint, the confirmation email fix moves to next sprint, and a few hundred more customers will hit the bug”.
• Keep one shared list. One board everyone can see beats five private conversations with five people.
• State your assumptions. Every number comes with a source or the word “estimate”. People can then challenge the assumption instead of challenging you.
• Say what would change the order. For example: “if sales has data showing the promotion brings more orders than we assumed, I'll review this on Friday”.

When a stakeholder still disagrees, do not try to win that conversation. Lay out the trade-off clearly and, if needed, take it to whoever has the authority to decide, with full information. How to say “not yet” and keep the relationship is covered in the article on saying no to stakeholders.

• Saying no to stakeholders without losing goodwill

Example: scoring five requests in a tea shop app

Back to Monday's five requests. This is an illustrative example and every number is an assumption, so you can see how the calculation works. Reach is customers per quarter, and Effort is person-months estimated by engineers.

How you read this table matters more than the numbers. The payment upgrade has the lowest score in the table, because customers see no change (Impact 0.25) and the integration takes effort. But it passed the three filter questions: a specific date, a partner notice, no workaround. So it goes first, because after the 30th customers cannot pay. The table still scores it so you can see the trap: looking only at scores, you would put it last. In real work, items with a real deadline are set aside first and not scored against the rest.

The email fix is second because the effort is small and support call counts give clear evidence. The discount code is third. It has a date, the end-of-month promotion, but the company set that date itself, it can move, and sales has a workaround: send a general code by email. So it does not count as a real deadline.

Zalo sign-in and the home page both have low confidence. The better move is to collect data before building: measure how many customers abandon sign-up, or whether the current home page makes people leave. If the data beats the assumption, the score rises and the order changes. That is what you tell marketing and the director, instead of a bare “not now”.

The result: next sprint covers the payment upgrade and the email fix. If there is room, the smallest version of the discount code. The other two get a review date and a list of the data needed.

A one-page priority note template

Once the order is set, send every relevant stakeholder a short note. One page is enough. The goal is that anyone reading it knows where their request stands, why, and what would change it. Copy the template below and adjust it to how your team talks.

Priorities for sprint [number] ([start date] to [end date])

Sprint goal: [one sentence, one objective, e.g. customers can pay through the new gateway before the partner's deadline]

We will do:
1. [Item] because [short reason, with evidence or deadline]
2. [Item] because [reason]

If there is room:
3. [Item] because [reason]

Not in this sprint:
- [Item] because [reason]. Review on [date]. Needed: [data or condition]
- [Item] because [reason]. Review on [date]. Needed: [data or condition]

Key assumptions:
- [Number or assumption], source: [data / person who confirmed / estimate]

What would change this order:
- [e.g. a large client hits the bug, the partner moves the deadline]

If this order looks wrong to you, reply by [date, time] with your reason or data and we will reconsider.

The “Not in this sprint” part is the most important part of the note. Each line needs a review date and a specific condition. Without them, people will message you every week. The “Key assumptions” part moves the debate to the numbers, instead of who speaks loudest.

Common backlog prioritisation mistakes

• Letting the score decide. A formula only reflects the assumptions you feed it. If the result looks wrong, check the assumptions instead of following it blindly.
• Scoring real deadlines like everything else. Work with a date and a concrete consequence must be pulled out first, or it can end up behind a higher-scoring item.
• Prioritising by the requester's title. A manager's request goes through the same questions as anyone's. If the manager still wants it first, say what moves back and let them decide with full information.
• Switching methods all the time. RICE this week and MoSCoW next week means stakeholders cannot compare decisions. Pick one and keep it for at least a few sprints.
• Estimating effort yourself. A PO guessing effort for engineers easily guesses wrong, and the team does not feel part of the decision.
• Announcing only what gets done. If you do not say what moved back, stakeholders will assume it was forgotten.

Summary

• Backlog prioritisation is a decision you must be able to explain. A method only makes the conversation less subjective.
• Value vs effort suits quick comparisons, MoSCoW suits fixing the scope of a release, RICE suits many competing ideas with some data.
• Pull out real deadlines first with three questions: is there a specific date, is the consequence checkable, is there a workaround.
• Make the trade-off visible: speak in pairs, “doing this moves that back”, keep one shared list, state your assumptions.
• Send a one-page priority note after every decision, with a review date and a condition for each item not being done.

I am writing more PO situations in this same format, with templates you can use straight away. If you would like the next one by email, subscribe to the newsletter below.

• Get new articles by email

Frequently asked questions

Who decides the order of the product backlog?

According to the Scrum Guide, the Product Owner is accountable for ordering the Product Backlog. Stakeholders bring information and reasons, and the PO sets the final order and must be able to explain it.

Should a new PO use RICE or MoSCoW?

MoSCoW suits agreeing the scope of a release with a fixed date. RICE suits comparing many ideas when you have some data on how many people are affected. A new PO can start with value vs effort and move on from there.

How do I tell if a request is really urgent?

Ask what happens if it is not done this month, on what date, and who bears the consequence. Real urgency usually has a date and a concrete consequence, such as a contract, a regulation or a system that stops working.

Sources to check

• Scrum Guide 2020: Product Owner
• Intercom: RICE prioritization
• ProductPlan: MoSCoW prioritization

Related articles

• What is a user story? How to write one, with examples: The “As a…, I want…, so that…” template is the easy part. This article shows how to pick a real user, a real problem and a small enough slice, with before and after examples.
• What are acceptance criteria? Writing them so QA can test: How to write acceptance criteria clear enough that QA knows exactly what to test, with a coupon example and ready-to-use templates.
• How to say no to your manager and stakeholders: Three ways to say no instead of a flat “no”, how to handle it when the request comes from your manager or CEO, when to escalate, with a sample dialogue and messages for each level.
• What is sprint planning? What a PO should prepare: A prep checklist for the day or two before sprint planning, how to run the “what” conversation, and how to write a Sprint Goal, with templates to use straight away.