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.



