Requirements Analysis & Specification

Prioritization: MoSCoW & Beyond

18 min Lesson 6 of 10

Prioritization: MoSCoW & Beyond

Every project has more requirements than time and money can accommodate. Prioritization is the discipline of deciding, explicitly and defensibly, which requirements deliver the most value and must ship first — and which can wait, be descoped, or be dropped entirely. Without a structured approach, teams default to "whoever shouts loudest wins," which reliably produces the wrong product.

This lesson covers the most widely used prioritization framework — MoSCoW — and then introduces the Value vs. Effort Matrix, a complementary tool for when you need to negotiate trade-offs with stakeholders using data rather than opinion.

The MoSCoW Framework

MoSCoW divides every requirement into one of four buckets. The name is a mnemonic — the vowels are added to make it pronounceable:

Must Have — Non-negotiable. The product cannot launch without this. If even one Must-have is missing, the release fails. Example: A clinic booking system must authenticate doctors before they can view patient records. Authentication is a legal and safety requirement — there is no workaround.
Should Have — Important but not immediately vital. A workaround exists, but it is painful. These are typically high-value items that were deprioritized only because Must-haves consumed the budget. Example: The booking system should send SMS appointment reminders. Receptionists can call patients manually — annoying, but functional.
Could Have — Nice to have. Low disruption if omitted. These are "bonus" features that add polish or convenience. Example: The booking system could show a map of the clinic on the confirmation page. Most patients already know where they are going.
Won't Have (this time) — Explicitly out of scope for this release. Critically, the "Won't" is not "never" — it signals a conscious, agreed decision to defer. Example: A mobile app for patients is a Won't for v1 — the web interface is sufficient; the app will be considered for v2.

The Won't bucket is as important as the Must bucket. Writing Won't-haves explicitly prevents scope creep — stakeholders cannot later claim "we never said it wasn't in scope" if it is documented.

A common rule of thumb for release planning: Must-haves should consume no more than 60–70% of available effort. If they consume 90%, there is no room to absorb estimation errors and the release becomes a crisis. Should-haves fill the next 20%, Could-haves are stretch goals.

MoSCoW in Practice: Online Grocery Store

Imagine a regional supermarket launching an online ordering platform. After a requirements workshop, the product owner lists 24 requirements. The team applies MoSCoW:

Must: User registration & login, product catalogue with search, shopping cart, secure checkout (card payment), order confirmation email, admin order management dashboard.
Should: Saved addresses, re-order from history, stock availability display, basic product reviews.
Could: Wish lists, loyalty point display, personalised product recommendations, dark-mode UI.
Won't (v1): In-store pickup scheduling, gift wrapping, live chat support, multi-currency, iOS/Android app.

The team now has a focused v1 scope. Every stakeholder signed off on the Won't list — so when the marketing director asks about the loyalty widget in sprint 3, the analyst can point to the agreed document rather than renegotiating from scratch.

The Value vs. Effort Matrix

MoSCoW answers "how critical is this?" — it does not directly answer "how expensive is this relative to the business value it delivers?" The Value vs. Effort Matrix (sometimes called the Impact vs. Complexity Matrix) maps both dimensions simultaneously, splitting the space into four quadrants:

Value vs. Effort Matrix: four quadrants guide sequencing and investment decisions across clinic, store, and logistics examples.

The four quadrants prescribe clear actions:

Quick Wins (High Value, Low Effort): Do these first. They build stakeholder confidence, deliver tangible results early, and are low-risk. SMS reminders for the clinic take two days to implement and reduce no-shows by 30%.
Strategic Bets (High Value, High Effort): Plan carefully. These justify significant investment but require phasing, PoCs, or phased delivery. Route optimisation for a logistics company could cut fuel costs 15% — but it needs careful data work. Commit to these in roadmap planning, not in panic.
Fill-ins (Low Value, Low Effort): Do if capacity remains at the end of an iteration. Never at the expense of higher-value work. These are often Could-haves in MoSCoW language.
Time Sinks (Low Value, High Effort): Resist strongly. Legacy fax integration for a logistics firm that has three fax-using customers is almost never worth it. These are Won't-haves unless a hard regulatory or contractual driver forces them.

Combining MoSCoW with the Value/Effort Matrix

The two tools are complementary. MoSCoW reflects criticality and risk (can we launch without it?). The matrix reflects return on investment (is the effort justified by the value?). A Must-have that is also High Effort must still be done — but the matrix flags that it needs careful planning. A Could-have that turns out to be a Quick Win should be promoted to Should-have and scheduled sooner.

Run the matrix exercise before finalising MoSCoW. Teams often assign Could-have to items that are genuinely Quick Wins simply because a senior stakeholder did not present them. The matrix surfaces these hidden gems.

Stakeholder Negotiation

Prioritization is a social process as much as an analytical one. Business sponsors often push every requirement toward Must-have. Common negotiation moves for analysts:

Ask the counterfactual: "What happens to the business on launch day if this feature is absent?" Forces sponsors to articulate real consequences vs. preferences.
Show the cost of Must-haves: Display the effort budget visually. When a sponsor sees their requirements already consuming 95% of the budget, they voluntarily reconsider.
Use Won't-have as a commitment device: Frame it as "we are committing to deliver this in v2 by [date]" rather than "we are cutting your feature." Losses feel larger than deferred gains.
Timebox the discussion: Prioritization workshops run long without a facilitator keeping time. Aim for 60–90 minutes per major feature area, with a parking lot for unresolved items.

Avoid MoSCoW inflation. If every requirement ends up as Must-have (common in inexperienced teams or under stakeholder pressure), the framework has no teeth. A useful heuristic: no more than 40% of requirements should be Must-have. If you exceed that threshold, challenge each one with the counterfactual question.

Beyond MoSCoW: Other Prioritization Techniques

For more quantitative contexts, two additional techniques are worth knowing:

Weighted Scoring: Score each requirement on multiple criteria (strategic alignment, revenue impact, risk reduction, user satisfaction) with agreed weights, and rank by total score. Useful for large backlogs where stakeholders span multiple business units with competing interests.
WSJF — Weighted Shortest Job First (SAFe): Prioritizes items by Cost of Delay ÷ Job Duration. A small feature that prevents a €50,000/week penalty should jump the queue over a large feature that adds €20,000/month if shipped later. Used heavily in Agile Release Trains managing complex dependencies.

For most projects, MoSCoW combined with the Value/Effort Matrix is sufficient and far more stakeholder-friendly than a spreadsheet full of weighted scores. Reserve the heavier techniques for enterprise programmes with multiple competing product lines.

Key takeaway: Prioritization is not about ranking a list — it is about reaching a shared, documented agreement on what success looks like for this release. The analyst's job is to facilitate that agreement, make trade-offs visible, and ensure every deferral is a conscious decision — not an oversight.