Prioritizing Needs with MoSCoW

Why Prioritization Is a Distinct Skill

Even after requirements have been elicited, documented, verified, and validated, not everything can be built at once. The Need domain expects a business analyst to rank requirements so that limited time, budget, and delivery capacity go toward the items that matter most first. BABOK v3 identifies several factors that drive prioritization decisions, and situation-based exam questions typically present a scenario where two or more of these factors point in different directions, requiring the candidate to weigh them against each other rather than apply a single rule mechanically.

Factors That Drive Prioritization

• Business value - how much benefit (revenue, cost savings, risk reduction, strategic alignment) the requirement delivers if implemented.
• Urgency - how time-sensitive the requirement is, independent of its value; a regulatory deadline or a licensing expiration can force urgency onto a moderate-value item.
• Risk - the likelihood and impact of negative consequences if the requirement is not implemented, or the risk introduced in implementing it.
• Dependencies - whether other requirements or components cannot proceed until this one is complete, which can force an otherwise low-priority item earlier in the sequence.
• Regulatory or compliance obligation - legal or contractual requirements that may override a pure value-based ranking.
• Stakeholder relationships and politics - the practical reality that stakeholder influence and organizational relationships sometimes affect sequencing, even though BABOK cautions against letting this factor dominate value-based prioritization.

MoSCoW: A Structured Way to Rank Requirements

MoSCoW is one of the most commonly tested prioritization techniques on the ECBA exam because it gives a simple, shared vocabulary for sorting requirements into four categories:

The value of MoSCoW is that it forces stakeholders to have an explicit conversation about trade-offs before development starts, rather than assuming everything requested is equally essential. A common mistake stakeholders make, and a common exam trap, is labeling nearly everything Must have. When that happens, the BA's role is to push back and ask what happens if the item is not delivered; if the answer is that the release still functions, just less optimally, it belongs in Should have or Could have, not Must have.

Applying MoSCoW Alongside Business Value and Urgency

MoSCoW categories and the underlying prioritization factors work together, not separately. A requirement can have high business value but land in Should have if it is not urgent and has an acceptable workaround. Conversely, a requirement with only moderate business value can be forced into Must have by urgency - for example, a security patch required to meet a regulatory deadline in two weeks has to be prioritized ahead of a higher-value feature with no deadline pressure, because missing the deadline carries a compliance consequence that outweighs the value comparison.

A Worked Approach for Exam Scenarios

When a situation-based question presents a prioritization conflict, work through it in this order: first identify each competing requirement's business value; second, check whether either has a hard deadline or dependency that creates urgency; third, check for regulatory or compliance obligations that override a pure value comparison; and finally, assign the MoSCoW category that reflects the combined answer. This sequence mirrors how BABOK expects prioritization to be reasoned through - value and urgency inform the category, rather than the category being assigned first and justified afterward. Practicing this order of operations on practice questions builds the instinct needed to move quickly through prioritization scenarios on exam day, where time per question is limited to roughly ninety seconds.

A Worked Example

Consider three competing requirements for a single release: a checkout-flow redesign with high estimated value but no deadline, a tax-calculation update with moderate value but a mandated go-live date tied to a new tax law, and a cosmetic color-scheme change requested by one stakeholder with low value and no urgency. Applying the reasoning above, the tax-calculation update becomes Must have despite its moderate value, because the regulatory deadline removes any flexibility. The checkout-flow redesign becomes Should have, since its high value is real but nothing forces it into the current release. The cosmetic change becomes Could have, or is deferred entirely to Won't have this time if capacity runs out. Working through the value, urgency, and compliance questions in sequence, rather than defaulting to whichever stakeholder pushes hardest, is what keeps the MoSCoW categories meaningful and defensible when a sponsor later asks why one item shipped and another was deferred.