Backlog prioritisation - an image of a product owner in front of a white board wit post-it notes

The Art (and Chaos) of Backlog Prioritisation

Reading Time: 4 minutes

If you’ve ever stared at a mountain of backlog items thinking, “Which of these should we actually do first?”, welcome to the club. Backlog prioritisation is both an art and a science. It’s judgment wrapped in frameworks, guided by data, coloured by politics, and shaped by customer need. And when done well, it becomes one of the most powerful levers a Product Owner has to deliver value fast.

Today, let’s unpack the four most common prioritisation methods: MoSCoW, WSJF, RICE, and Value/Effort, and walk through how they might rank the same backlog items differently. Because the magic is not in knowing the frameworks, but in knowing which lens helps you make the right decision at the right time.

 

Why Prioritisation Matters 

In Agile teams, prioritisation isn’t a one-off exercise. It’s a discipline. It’s what helps you:

  • Deliver value early and often
  • Avoid wasting time on “nice ideas” with low impact
  • Guide stakeholders on why you’re choosing X over Y
  • Keep engineers focused and unblocked
  • Maintain alignment with strategy and customer outcomes

A clear prioritisation process gives your team confidence and your stakeholders fewer reasons to say, “But why isn’t my item done yet?”

 

Example

Imagine we are building a Pantry Organizer App.

Here are five backlog items we’ll prioritise through each method:

ID

Backlog Item

A

Add barcode scanning for quick item entry

B

Add push notifications before expiry dates

C

Add AI-powered recipe suggestions

D

Add dark mode

E

Improve database query speed by 30%

Now let’s put these items through the four prioritisation frameworks and see what happens.

 

MoSCoW Prioritisation

MoSCoW sorts items into Must, Should, Could, and Won’t (for now).

How it looks:

  • Must: Critical for launch, compliance, or core user value
  • Should: Important but not critical
  • Could: Nice-to-have
  • Won’t (now): Deferred intentionally

Our example (as a PO):

  • Must: A (Barcode scanning), B (Expiry notifications)
  • Should: E (Performance improvement)
  • Could: C (AI recipe suggestions), D (Dark mode)
  • Won’t: none

Outcome:

A → B → E → C → D

Benefits:

  • Simple, intuitive, fast
  • Excellent for early-stage or MVP scoping
  • Helps stakeholders understand trade-offs

Shortcomings:

  • No quantification , it is subjective
  • Too many items often end up in “Must”
  • Doesn’t help sequence items within categories

 

WSJF (Weighted Shortest Job First)

Used heavily in SAFe, WSJF calculates:

(Business Value + Time Criticality + Risk Reduction) ÷ Job Size

Business Value (BV)

What it means:
How much this item contributes to customer value, revenue, retention, or strategic goals.

How to score:

  • 1 = Minimal value
  • 5 = Useful but not game-changing
  • 10 = Major impact on customers or business

Think: “How valuable is this if we deliver it?”

Time Criticality (TC)

What it means:
How urgent the item is — whether delay reduces value.

How to score:

  • 1 = No urgency; value doesn’t decay
  • 5 = Important for upcoming release or event
  • 10 = Value drops sharply if delayed (e.g., seasonal, compliance, contract deadlines)

Think: “Does waiting make this worse?”

Risk Reduction / Opportunity Enablement (RR/OE)

What it means:
How much this item reduces risk (tech, business, compliance) or unlocks future opportunities.

How to score:

  • 1 = No real risk reduced or opportunities unlocked
  • 5 = Moderate reduction of uncertainty
  • 10 = Removes major risks or enables key architectural or business capabilities

Think: “Does this make future work easier or safer?”

Job Size (JS)

What it means:
Estimate of how much effort is required — often using story points, t-shirt sizes, or a simple scoring scale.

How to score:

  • 1 = Very small (hours)
  • 5 = Medium (days)
  • 10 = Large (weeks)

Think: “How big is this compared to other items?”

Let’s score the items (1–10 scale):

Item

BV

TC

RR

Job Size

WSJF Score

A

9

6

5

5

4.0

B

8

9

4

3

7.0

C

7

4

6

8

2.1

D

3

2

1

2

3.0

E

6

7

8

4

5.25

Outcome:

B → E → A → D → C

Benefits:

  • Prioritises speed of value delivery
  • Favors high-impact, low-effort work
  • Reduces emotional decision-making

Shortcomings:

  • Scoring can be subjective (again!)
  • Can favour short-term wins over long-term innovation
  • Requires discipline to score consistently

 

RICE (Reach, Impact, Confidence, Effort)

Ideal for product-led growth or when you have data.

RICE formula:
(Reach × Impact × Confidence) ÷ Effort

Where Reach is number of users impacted and Impact predicts the severity of the impact from barely noticeable to game-changing.

Example scoring:

Item

Reach

Impact

Confidence

Effort

RICE

A

7

7

90%

5

8.8

B

9

6

85%

3

15.3

C

6

8

60%

8

4.5

D

5

3

95%

2

7.1

E

8

5

80%

4

8.0

Outcome:

B → A → E → D → C

Benefits:

  • Data-driven
  • Great for roadmap transparency
  • Confidence factor helps reduce “wishful thinking”

Shortcomings:

  • Requires access to good data
  • Time-consuming if you have a large backlog

 

Value / Effort Matrix

The simplest of all — place each item on a 2×2 matrix:

  • High Value / Low Effort → Do first
  • High Value / High Effort → Plan
  • Low Value / Low Effort → Do if time permits
  • Low Value / High Effort → Probably don’t do

Our categorisation:

  • High Value / Low Effort: B, A
  • High Value / High Effort: E, C
  • Low Value / Low Effort: D
  • Low Value / High Effort: None

Outcome:

B → A → E → C → D

Benefits:

  • Very easy to apply
  • Great for quick prioritisation sessions
  • Helps visual thinkers

Shortcomings:

  • Oversimplified
  • “Value” is often subjective
  • Doesn’t scale well for big backlogs

 

Comparing the Results Side-by-Side

Method

Priority Order

MoSCoW

A → B → E → C → D

WSJF

B → E → A → D → C

RICE

B → A → E → D → C

Value/Effort

B → A → E → C → D

What we learn:

  • B (Expiry Notifications) consistently rises to the top → small effort, high user value.
  • C (AI Recipe Suggestions) is always last or second-last → big effort, less urgent.
  • Frameworks differ most on mid-tier items like A and E.

This is the heart of backlog prioritisation:

Frameworks are tools, not the decision.
The Product Owner still needs to balance strategy, risk, tech constraints, and upcoming milestones.

 

So Which Method Should You Use?

Choose based on context:

  • MoSCoW → Early-stage, MVP, stakeholder alignment
  • WSJF → When you need to maximise flow and manage risk
  • RICE → Data-rich environments, growth teams, experiments
  • Value/Effort → Quick decisions, small teams, early grooming

The most effective Product Owners use more than one approach — starting simple, adding sophistication as the product matures.

 

Final Thought

Backlog prioritisation isn’t about choosing the “perfect” method. It’s about creating clarity. It’s about showing your team and stakeholders why you’re moving in a particular direction. Frameworks help you structure the conversation — but judgment, empathy, and strategic thinking make you a great Product Owner.