Agile Prioritization Techniques: 10 Methods and How to Choose

Reviewed by [Reviewer name], [CSPO, CSM or SAFe credential]. Last updated [date].

What are agile prioritization techniques? Agile prioritization techniques are structured ways to decide the order in which a team works on backlog items, so the most valuable work is delivered first. The most widely used are MoSCoW, RICE, WSJF, the Kano model and the value vs effort matrix. In Scrum, the Product Owner is accountable for ordering the Product Backlog, using techniques like these to make trade-offs visible and agreed.

The five techniques most teams need are MoSCoW, the Kano model, RICE, WSJF, and the value versus effort matrix. They are not interchangeable. MoSCoW suits fixed deadlines, Kano suits understanding what customers actually value, RICE suits comparing product ideas with data behind them, WSJF suits deciding sequence when delay has a cost, and value versus effort suits a team that needs a decision in ten minutes.

This guide covers those five in depth, then five more for specific situations: stack ranking, Cost of Delay, ICE scoring, the 100 dollar test and priority poker.

Key Highlights

• Choosing a technique matters more than executing one perfectly. Most teams pick the first one they read about and force everything through it.
• MoSCoW works when time is fixed and scope can flex. It falls apart when everything gets labelled Must.
• RICE and WSJF produce a number, which makes them useful for defending a decision and dangerous when the inputs are guesses.
• The Kano model answers a different question from the others: not what to build first, but what will actually satisfy anyone.
• Simple beats sophisticated for most teams. A two by two grid used consistently outperforms a scoring model used once and abandoned.
• Prioritization is the Product Owner's accountability. The technique is a tool for making that decision visible, not a way to avoid making it.

Why Technique Choice Matters

Most articles list eight methods with definitions and leave you to guess. The guessing is the hard part, and picking wrongly wastes more time than not having a method at all.

The techniques answer genuinely different questions.

What must ship by the deadline? MoSCoW.

What will customers actually notice? Kano.

Which of these competing ideas gives the best return? RICE.

What order should we do these in, given that waiting costs us? WSJF.

What can we decide quickly without much data? Value versus effort.

A team using RICE to decide what fits before a regulatory deadline is using the wrong tool, and so is a team using MoSCoW to compare twenty product ideas. The failures usually get blamed on the technique rather than the choice.

If you are building the Scrum foundation this sits on, our free CSM practice test is a quick way to check where you stand.

Five Core Agile Prioritization Techniques

MoSCoW

The most widely used and the most widely misused.

What it is. Every item is classified as Must have, Should have, Could have, or Will not have this time. It comes from DSDM, which is worth knowing because the method assumes the DSDM context of a fixed timebox with flexible scope, covered in our comparison of DSDM and Scrum.

When it works. A fixed deadline with negotiable scope. A regulatory date, a contracted launch, an event. The categories give everyone a shared language for what gets cut if time runs short.

The failure mode. Everything becomes a Must. This happens in almost every organisation that adopts MoSCoW without a constraint, and once eighty percent of the backlog is Must, the method has produced a list in a different order and no information.

The fix that makes it work. Cap the Must category by effort, not by count. DSDM guidance from the Agile Business Consortium is that Must Have effort should generally be no more than about sixty percent of a timebox, with Could Haves around twenty percent as contingency (MoSCoW Prioritisation). That leaves genuine room for the rest. Without a cap, MoSCoW degrades within two Sprints.

On the fourth category. Will not have this time is the most valuable letter and the one most often dropped. Explicitly deciding what is out, and recording it, prevents the same conversation recurring every planning session.

The Kano Model

The one that answers a different question, which is why it is often misunderstood.

What it is. A way of classifying features by how they affect customer satisfaction, developed by Professor Noriaki Kano in 1984. Must-be features are expected and cause dissatisfaction if missing (for example, secure login). One-dimensional, or performance, features increase satisfaction the better they are (for example, faster page loads). Attractive features delight customers who did not expect them, and their absence is not noticed. Indifferent features make no difference, and Reverse features annoy some users. Teams usually classify features with a short survey that asks how users would feel if a feature were present and if it were absent.

When it works. Deciding what to build to move satisfaction, particularly when a team keeps shipping features nobody reacts to. It is genuinely useful for understanding why a large investment landed flat.

What it does not do. It does not sequence work. Kano tells you which category something falls in, not what to do on Monday. Teams that adopt it as their only prioritization method end up with classified items and no order.

The insight most teams miss. Categories migrate over time. Today's delighter becomes tomorrow's basic expectation as competitors adopt it. A feature that once differentiated a product eventually becomes something customers are annoyed to find missing, and planning as though the classification is permanent leads to underinvesting in the basics.

Practical use. Best combined with something else. Use Kano to understand what matters, then use a sequencing technique to decide order.

RICE

The most defensible when the inputs are real.

What it is. A score calculated as reach multiplied by impact multiplied by confidence, divided by effort. Reach is how many users are affected in a period. Impact is how much it moves the thing you care about. Confidence is how sure you are of the first two. Effort is the cost, usually in person-months.

Why the confidence term matters. It is the part that makes RICE better than a simple value over effort calculation. An idea with a huge estimated impact and a guess behind it gets discounted automatically, which stops loud speculation from beating quiet evidence.

How it is scored. Using Intercom's published scales (Sean McBride, Intercom), Reach is people or events per period, such as customers per quarter. Impact is 3 (massive), 2 (high), 1 (medium), 0.5 (low) or 0.25 (minimal). Confidence is 100% (high), 80% (medium) or 50% (low). Effort is person-months. RICE = (Reach x Impact x Confidence) / Effort.

Dark mode reaches the most people but ranks last, because its impact is low and nobody is confident about it. That is the confidence term doing its job.

When it works. Comparing a set of product ideas where you have some data. Product teams choosing between initiatives get real value from it.

The failure mode. Fabricated precision. If reach and impact are invented, the score is invented too, and a number carries far more authority than a guess deserves. Teams end up defending decisions with arithmetic built on assumptions nobody examined.

The honest test. For each input, ask where the figure came from. If more than one is a guess, the ranking is a guess wearing a decimal point.

WSJF

The sequencing method, and the one most misapplied outside its context.

What it is. Weighted Shortest Job First, calculated as Cost of Delay divided by job size. In SAFe, Cost of Delay is the sum of three relatively scored components: user and business value, time criticality, and risk reduction and/or opportunity enablement (Scaled Agile Framework). Teams often score each on a modified Fibonacci scale. WSJF sequences work so that the highest value per unit of time comes first.

Audit logging goes first: it has the lowest business value but is small and time-critical, which is exactly the trade-off WSJF is designed to surface.

When it works. When delay genuinely costs something and the items are roughly independent. It is at its strongest with a queue of work competing for the same capacity.

The concept worth taking even if you never use the formula. Cost of delay is the useful idea here. Asking what it costs us to do this three months later rather than now changes conversations, because it surfaces that some work loses most of its value if it slips while other work loses none.

The failure mode. Applying it to items that are not independent, or where cost of delay is unknowable. Also, like RICE, producing a number from estimates and then treating the number as fact.

Full mechanics, including how the cost of delay components are scored, are in our guide to WSJF.

Value Versus Effort

The simplest, and the right default for most teams.

What it is. A two by two grid. High value and low effort goes first. High value and high effort gets planned properly. Low value and low effort is filler. Low value and high effort gets deleted.

When it works. Almost always, as a starting point. It takes ten minutes, needs no data, and produces a decision the whole team can see the logic of.

Why it beats sophisticated methods in practice. It gets used. A team that runs this grid every refinement session for a year will make better decisions than a team that built an elaborate scoring model, used it twice, and quietly stopped.

Its limitation. It cannot distinguish between items in the same quadrant, so with twenty things in the high value high effort box you need something else. That is the point to reach for RICE or WSJF, not before.

The quadrant people avoid. Low value and high effort. The technique's real contribution is giving the team permission to delete things, and a backlog that only ever grows is a backlog nobody is prioritizing.

Five More Prioritization Techniques

These suit narrower situations, and each fills a gap the core five leave.

Stack Ranking

What it is. Every backlog item is ordered in a single list with no ties: item 1 is more important than item 2, and so on.

How it works. Compare items two at a time and move the more valuable one up until the list is stable.

Best for small backlogs and teams that need a clear next item. Watch out: it can hide dependencies and does not show how much more valuable one item is than another.

Cost of Delay

What it is. An estimate of how much value you lose for each period an item is not delivered.

Example. If Feature A earns $50,000 a month and Feature B earns $10,000 a month, every month A waits costs five times more than B.

Best for time-sensitive work such as regulatory deadlines or seasonal launches. Watch out: it needs credible value estimates, and it should be combined with job size, as WSJF does, so large items do not crowd out quick wins.

ICE Scoring

What it is. Each item is rated on Impact, Confidence and Ease from 1 to 10, and the three are multiplied: ICE = Impact x Confidence x Ease. A higher Ease score means less effort.

Best for fast scoring of growth experiments and ideas. Watch out: scores are subjective, so agree what a 3 and an 8 mean before scoring.

100 Dollar Test (Buy a Feature)

What it is. Each stakeholder gets 100 points, or play money, to spread across backlog items.

How it works. 1. List the candidate items. 2. Each person allocates their 100 points. 3. Total the points and rank by score.

Best for aligning several stakeholders quickly. Watch out: people may put all their points on one favourite item, so cap the maximum per item if needed.

Priority Poker

What it is. Priority poker works like planning poker but rates value instead of size.

How it works. 1. The Product Owner presents an item. 2. Each participant privately picks a priority score, for example 1 to 5. 3. Everyone reveals at once. 4. The highest and lowest voters explain their reasoning. 5. Re-vote until scores converge.

Best for surfacing different assumptions across business and technical roles.

Choosing Between Them

That last row is worth dwelling on. Techniques are for the hard cases, and the ordinary work of keeping a Product Backlog in order does not need a framework. A Product Owner who runs a scoring model on every item has turned a judgement into a ceremony.

A Worked Comparison

The same backlog run through three techniques shows why the choice matters.

A team has five candidate items: a checkout redesign, a compliance change with a legal deadline, an export feature three enterprise customers have asked for, a performance fix affecting all users, and a redesigned settings page.

Through MoSCoW. Compliance is a Must, since the deadline is external and non negotiable. Performance is a Should. Export and checkout are Coulds. Settings is a Will not have this time. Useful, and it produces categories rather than an order. Checkout and export sit in the same bucket with nothing to separate them.

Through value versus effort. Performance is high value and low effort, so it goes first. Compliance is moderate value and high effort but has a deadline that the grid does not capture at all. Checkout is high value and high effort. Export is moderate value and low effort. Settings is low value and moderate effort, so it gets deleted. Fast, and it produced a deletion, which MoSCoW did not.

Through WSJF. Compliance has an enormous cost of delay, since missing the date carries a penalty, and it rises to the top despite its size. Performance has a steady cost of delay and a small job size, so it comes second. Export has a low cost of delay unless a renewal is at risk, which is the question WSJF forces someone to answer.

Three techniques, three different answers, none of them wrong. MoSCoW protected the deadline, value versus effort found the quick win and the item to delete, and WSJF produced the sequence.

The practical lesson is that running two cheap techniques over the same list takes twenty minutes and surfaces more than running one carefully. Where they disagree is where the interesting conversation is.

Prioritizing When You Have No Data

Most advice assumes reach and impact figures exist. Frequently they do not, particularly for a new product or an internal tool.

Four approaches that work without data.

Ask what breaks if we do not do this. Nothing means it is not a priority, whatever anyone claims. This single question removes more items than any scoring model.

Look for the smallest thing that tests the assumption. If you cannot tell whether a feature matters, the priority is finding out cheaply rather than building it fully.

Use relative comparison rather than absolute scoring. People are poor at estimating that a feature will lift retention by four percent, and reasonably good at saying this matters more than that. Pairwise comparison is more reliable than invented numbers.

Count who is asking and why. Three enterprise customers requesting the same thing is weak evidence, and it is evidence. One loud internal opinion is not.

The mistake to avoid is manufacturing data to feed a technique that requires it. A RICE score assembled from invented inputs is less honest than admitting the decision was a judgement call, because it dresses the judgement in arithmetic and makes it harder to challenge.

Teams without data are usually better served by the simplest technique and a short written note explaining the reasoning. The note is worth more than the score six months later, when someone asks why an item was skipped.

Where Prioritization Actually Happens

Worth locating this in the Scrum events, because the techniques are often discussed as though they float free of any process.

Ongoing, in refinement. The bulk of it. As items are refined and understood, their relative order becomes clearer, and the Product Owner adjusts. Our guide to backlog refinement covers the mechanics.

At the top of the backlog, continuously. Only the next Sprint or two needs to be finely ordered. Precisely ranking item ninety is wasted effort, because priorities will have changed before you reach it.

In Sprint Planning, lightly. The backlog should already be ordered when planning starts. What happens there is confirming which items serve the Sprint Goal, not re-prioritizing from scratch. If planning routinely turns into a prioritization debate, the ordering work is not happening beforehand, as covered in the Product Owner's role in Sprint Planning.

Not mid Sprint. Reordering during a Sprint in a way that threatens the Sprint Goal is where prioritization becomes disruption.

The applied guides to prioritizing user stories and ordering the product backlog cover the day to day practice in more detail than this overview does.

Who Decides

A source of genuine confusion, and the answer is unambiguous in Scrum.

The Product Owner is accountable for ordering the Product Backlog, as the 2020 Scrum Guide states. Not the Scrum Master, not the loudest stakeholder, not a committee.

That does not mean deciding alone. A Product Owner should be drawing on the Developers for effort and technical dependency, on stakeholders for business context, and on data where it exists. What they cannot do is delegate the decision, because a backlog ordered by consensus is usually ordered by whoever argued longest.

Where the techniques help is making the reasoning visible. A stakeholder who disagrees with a decision but can see how it was reached will usually accept it. A stakeholder told only that something is not a priority will escalate.

Where the techniques hurt is when they are used to avoid the decision. Producing a score and pointing at it, when the inputs were assembled to produce that score, is a way of not being accountable. The Scrum Master noticing that pattern and naming it is part of the job, and it is the kind of judgement CSM Certification Training covers directly.

Common Mistakes

Everything is high priority. If the top of the backlog has thirty items marked urgent, nothing is prioritized. The test for any technique is what it says no to.

Prioritizing the whole backlog. Effort spent ranking items sixty through two hundred is wasted, since they will be reordered or deleted before anyone reaches them.

Confusing priority with sequence. Two items can be equally important while one clearly has to come first for technical reasons. Dependencies constrain order regardless of value.

Changing the method every quarter. Consistency produces comparability. A team that switches technique repeatedly cannot tell whether its decisions are improving.

Scoring without revisiting. A RICE score from six months ago reflects assumptions that have since changed. Scores decay.

Letting the loudest stakeholder win. The most common failure of all, and no technique fixes it on its own. What techniques do is make the override visible, which is usually enough to reduce how often it happens.

Treating the technique as the deliverable. A beautifully maintained scoring spreadsheet that nobody consults before planning is overhead, not prioritization. The output should be a shorter, better ordered backlog, and if the artefact grows while the backlog does not improve, the method has become the work. Spotting that drift and calling it out is a normal part of the Scrum Master role, covered in CSM Certification Training.

Closing Thoughts

The value of a prioritization technique is not the ranking it produces. It is the conversation it forces and the record it leaves of why a decision was made.

That reframing changes which technique to pick. The best one is the one your team will actually use every refinement session, which for most teams is the simplest one available. A two by two grid used consistently beats a scoring model used twice, and elaborate methods tend to be adopted enthusiastically and abandoned quietly.

The other thing worth holding onto is that no technique makes the decision for you. They organise the inputs and make the reasoning visible, and the judgement still belongs to the Product Owner. A team looking for a method that removes the need to choose is looking for something that does not exist.

If you are supporting a Product Owner through these decisions or facilitating the sessions where they happen, CSM Certification Training covers the Scrum framework and the facilitation that keeps prioritization conversations productive. Request the curriculum to see the agenda and upcoming dates, or start with the free CSM practice test to find your gaps first.

References

• Sean McBride, "RICE: Simple prioritization for product managers", Intercom, 2018.
• Scaled Agile Framework, "Weighted Shortest Job First (WSJF)".
• Agile Business Consortium, DSDM Handbook, "MoSCoW Prioritisation".
• Noriaki Kano et al., "Attractive Quality and Must-Be Quality", 1984.
• Ken Schwaber and Jeff Sutherland, The Scrum Guide, 2020 (Product Owner accountability for the Product Backlog).