A large share of scenario questions boil down to one thing: the team cannot do everything, and you have to decide what gets done first. Sometimes the question names a technique. More often it describes a situation — a sponsor wants a feature added mid-iteration, a stakeholder calls three items "critical," a backlog has grown faster than the team's capacity — and expects you to recognize which prioritization method fits.
This article covers four techniques that appear in prioritization scenarios, what each one actually measures, and the clue patterns that point to one rather than another.
Why prioritization shows up so often
Two things make this topic worth a dedicated study session.
The first is the exam's structure. The current exam content outline runs three domains — People at 33%, Process at 41%, and Business Environment at 26% — across 26 tasks, and took effect on 9 July 2026. Business Environment is described in terms of strategy, value, and compliance, which is exactly the frame prioritization questions use.
The second is PMI's stated direction for the refreshed exam. PMI's own roadmap says the exam launched worldwide in July 2026, emphasizes agile and hybrid approaches over predictive ones, and emphasizes value delivery over scope, schedule, or cost. When a question asks what to deliver first, "the highest-value item" is the thinking the exam is built around — the techniques below are just different ways of defining value.
Note that enablers listed under each task are illustrative rather than exhaustive, so no published list guarantees a specific technique by name. Treat these four as patterns to recognize, not as a memorization checklist.
MoSCoW: four buckets, agreed with stakeholders
MoSCoW sorts requirements into four categories:
- Must have — critical. The deliverable does not work without them.
- Should have — important, but can be postponed if time or resources run short.
- Could have — desirable, adds value, not essential.
- Won't have — explicitly out of scope for this release or iteration.
The useful part is the fourth bucket. MoSCoW forces a conversation about what is being deliberately excluded, which is why it fits questions where stakeholders are labeling everything as urgent. If a scenario has three stakeholders each insisting their item is top priority, the answer is rarely "escalate" — it is usually to facilitate a session where the group classifies items together and agrees on the Won't-have list.
Kano model: what customers notice
Kano sorts product attributes by the kind of satisfaction they produce, rather than by urgency:
- Threshold (basic) attributes — what customers simply expect. Having them does not raise satisfaction; missing them causes complaints.
- Performance attributes — satisfaction rises in proportion to how much you provide.
- Excitement attributes (delighters) — unexpected features that exceed expectations.
Kano is not a calculation. It is a way of explaining why polishing a feature nobody asked about is a poor trade against a basic expectation that is still missing. Look for it when the scenario is about customer satisfaction, user research, or a debate over whether a flashy feature is worth the effort.
The 100 points method: distributed voting
Participants each receive 100 points and distribute them across backlog items however they choose. Totals are summed, converted to percentages, and the highest score ranks first. The method was proposed by Dean Leffingwell and Don Widrig in 2003.
Its strength is that it surfaces relative intensity, not just rank order. A stakeholder who spends 60 of their 100 points on one item has told you something a simple ranked list would not. Expect it in scenarios with a group of stakeholders, no shared authority, and a need for a defensible outcome.
A related technique, paired comparison analysis, compares items two at a time to establish relative importance. It suits short lists where a group cannot agree on a single ordering.
WSJF: cost of delay divided by job size
Weighted Shortest Job First is the only one of the four with arithmetic behind it. WSJF is calculated by dividing the cost of delay by the job size. Cost of delay is built from three components:
- User-business value — what the item is worth to the business
- Time criticality — how urgent it is
- Risk reduction / opportunity enablement — whether it reduces risk or opens an opportunity
Job size is the item's size relative to others. The division is what matters: smaller items are favored over larger ones at the same cost of delay, so two items of equal value do not rank equally if one is three times the effort.
WSJF fits scenarios involving an economic argument — a sponsor asking why a smaller item went first, or a team debating whether a large high-value epic should block several quick wins.
Choosing between them
| Technique | What it measures | Strongest clue in the question |
|---|---|---|
| MoSCoW | Negotiated necessity | Everything is labeled "critical"; scope needs explicit exclusions |
| Kano | Type of customer satisfaction | Customer expectations, satisfaction surveys, feature debates |
| 100 points | Relative intensity of stakeholder preference | Several stakeholders, no single decision-maker |
| Paired comparison | Relative importance, item by item | Short list, no agreement on ordering |
| WSJF | Economic value per unit of effort | Cost of delay, effort versus payoff, sequencing |
How prioritization questions are usually built
Three patterns recur.
- Named technique, unclear application. The question names MoSCoW or WSJF and asks what the project manager does next. The answer is almost always to run the technique with the people who have the information — not to decide alone.
- Unnamed technique, described situation. The question describes the problem and the distractors are four techniques. Match the clue to the column above.
- Prioritization as a distractor. The real issue is governance or change control, and a prioritization option is there to tempt you. If a scenario involves a baselined scope in a predictive project, reprioritizing a backlog is usually not the answer; a change request pathway is.
Common traps
- Deciding without the stakeholders. Prioritization is a facilitated activity. An option where the project manager reorders the backlog unilaterally is usually wrong.
- Treating urgency as value. Time criticality is one of three inputs to cost of delay, not the whole of it. A loud deadline does not automatically outrank a larger business benefit.
- Ignoring job size. Candidates who remember "highest value first" and forget the divisor pick the large epic over three quick wins.
- Applying agile tools to predictive scenarios. If the question has a signed baseline and a formal change process, backlog reprioritization is out of place.
- Confusing Kano's threshold attributes with Must-haves. They overlap in practice but answer different questions: Kano asks what customers notice, MoSCoW asks what the team committed to.
Before exam day
Work through a handful of practice questions where you write down, before looking at the options, which of the five techniques the scenario is describing and why. That habit is what converts a memorized list into a usable decision rule — and it is the same habit that makes value-based questions tractable across all three domains.