Grouping

Goal

Grouping turns a long list of requirements into a small number of decision-ready bands. The problem it solves is a fixed-scope increment, a release, a timebox or a set budget: the team has to agree quickly on what it must contain and on what gets cut first. Priority stops being an opinion each person holds in their head and becomes a written category, agreed in the session. The day a requirement is deferred, there is a difference between reopening the decision and pointing out "it's a Should, we decided that together".

Grouping is one of the four prioritisation approaches BABOK distinguishes, alongside ranking, time boxing and budgeting and negotiation. The same family also gathers collaborative approaches such as dot voting and the bullseye. Grouping contributes a partition into bands, with no order inside a band, built from written definitions everyone reads the same way.

The deliverable lives in the working tool. Each requirement carries a priority attribute, its band, usually a field in the product backlog or the requirements repository. BABOK notes that many requirements management tools allow this category to be listed as an attribute of a requirement. The artefact is a property of the requirements, revised at every planning cycle.

Usage

When to use it

• Fixed-scope or fixed-budget delivery: give an agreed basis for what drops first if time runs short.
• Large requirement set: a full item-by-item order would cost more negotiation than the decision is worth.
• Need for a shared vocabulary of importance: replace the "high, medium, low" each stakeholder reads their own way.
• Requirements set to evolve: make priority an attribute revised at each planning cycle.
• Several stakeholder groups: reach a scope consensus quickly without ranking everything against everything.

When not to use it

• Two items in the same band must ship in a set order: grouping does not say which comes first, take ranking to sequence them.
• A hard resource ceiling with no room to negotiate: start from the resource with time boxing and budgeting, the bands then serving only as the allocation rule.
• Fundamental disagreement on what matters: the category scheme is not the obstacle, run negotiation before sorting.

Description

The four categories and the rule that holds them together

MoSCoW places each requirement in exactly one of four categories, each carrying a precise, agreed definition. The acronym reads off its initials, the two o's there only to make it pronounceable.

The Must have is non-negotiable. It forms the minimum usable subset. The test is a single question, "what happens if this is not delivered": if the only honest answer is to cancel the delivery, it is a Must. The Should have is important without being vital. Its absence hurts without blocking release, because a workaround exists in the short term, a manual step or a postponement. The Could have is wanted, with markedly less impact if it is left out. It forms the contingency pool, the first thing given up as soon as a Must or a Should is at risk. The Won't have this time is a dated deferral: the requirement is agreed out of scope for this timeframe and stays a candidate for the next cycle. Writing that deferral down keeps the requirement from resurfacing and reopening a closed discussion.

Sorting into fixed bins

Grouping partitions, it does not rank within a band. Two Musts are equally Must, and MoSCoW does not say which is built first. When the real question becomes "which of these two Musts first", typically because one depends technically on the other, it is ranking that is needed: it produces a total order where grouping produces only bands. The bins are fixed and known in advance, and the requirements fall into them.

MoSCoW

On top of this partition sits an effort rule that comes from DSDM and the Agile Business Consortium and has no equivalent in BABOK. Musts should not exceed 60% of the total estimated effort of the increment, and Coulds form a contingency pool of roughly 20%. Beyond 60% of effort in Musts, delivery predictability is compromised, save in a well-understood environment, with an established team and low external risk. This proportion turns a sum of individual judgements into a budget that can be checked: if the Musts consume three quarters of the increment, the conclusion is that some items are mis-graded.

Running the sort

1. Publish the band definitions before any sorting
   The four from DSDM or in-house categories if MoSCoW is not the convention, written and precise.
2. Assign each requirement to exactly one band
   With the stakeholders able to speak to business value, risk and urgency.
3. Check the effort balance after the first pass
   Sum the estimated effort per band. If the Musts clearly exceed 60%, some items are overestimated and call for re-examination.
4. Record the Won'ts
   Keep them visible for the next cycle, where they come back as dated, revisable decisions.
5. Replay the assignment as the project progresses
   BABOK notes that the analyst revisits priorities when changes occur.

What makes the exercise fail

Must-inflation is the most common failure. Everything ends up called a Must, either because the categories were agreed too loosely or because the requirement was stated at too high a level to be arbitrated. The remedy, drawn from DSDM practice, is to decompose before grading. A coarse requirement such as "view the account balance" is a Must, but its multi-currency display variant, once isolated through functional decomposition, often turns out to be a Should or a Could. A Must that is too big often hides Coulds inside it.

The missing Won't is the counterpart of Must-inflation. Teams readily grade into Must, Should and Could but never assign a Won't. Out-of-scope items then sit in an ambiguous "maybe later", where a Won't would have made them a recorded, revisable decision. A MoSCoW list with no Won't at all has almost always dodged the hard choices.

Bands with no decision rule are the third breakdown. A "high, medium, low" with no stated test, what makes a thing high, falls back on the balance of power in the room. BABOK, for its part, notes among the limits of prioritisation three hazards that MoSCoW does not cancel on its own: stakeholders who dodge the hard trade-offs; a delivery team that overstates implementation difficulty to sway the prioritisation; the frequent absence of hard metrics, which keeps the exercise subjective as long as no discipline frames it. That discipline is the written definition of the bands and the check on the effort balance.

AI considerations

The first use is the first-pass sort. A language model given the requirement text proposes a band assignment for each one, which a human confirms or corrects. On a backlog of several hundred lines, this triage spares the most tedious part and leaves judgement where it counts, on the contested cases.

The second use is the most profitable: detecting inconsistent grading. Two near-identical requirements one of which is Must and the other Should, a requirement of plainly lower value marked Must while stronger neighbours are Could, the model spots these contradictions across hundreds of lines as a room never will. It likewise computes the effort sum per band and flags when the Musts cross the 60% threshold.

What AI must not do comes down to the nature of the band. A requirement's business value is a stakeholder decision anchored in a context the model does not have: a regulatory exposure, a political sensitivity, a commitment made to a specific client. A model cannot be the sole author of a Must, Should, Could or Won't verdict that would then be treated as agreed, because the whole value of MoSCoW is the human agreement behind the label. A band produced by the machine and adopted with no session is a label with no commitment. Finally, a backlog often carries sensitive strategic information, unannounced pricing, undisclosed features, so handing it to an external tool is a data-handling decision.

Examples

A health insurer in French-speaking Switzerland is preparing the next release of its members' self-service portal, a fixed-budget increment of CHF 180'000 over twelve weeks.

The premium simulator is a Could, the first candidate for dropping if a Must slips, because the portal stays usable without it. The chatbot appears in the list as Won't have this time, a dated decision to defer it, and having written it down keeps it from resurfacing in three weeks as a fresh request to re-arbitrate. If the estimate then showed the two Musts consuming three quarters of the twelve weeks, that would be the signal to reopen their breakdown rather than trim the Shoulds, in line with the 60% rule.

Visualisations

The list of bands is made of rows and columns. Written in HTML, the band attribute can be sorted, filtered, counted by formula and copied back into the backlog tool, which an image of a table forbids. The band carries a written definition readable on the artefact, the Won't appears on the same footing as the other three bands, and each requirement occupies exactly one row in a single band.

The sorting mechanism, on the other hand, does not fit into a table, because it rests on positions and proportions. It is drawn: an incoming batch of requirements, four fixed labelled bins that receive them and the effort budget made visible by the size of the bins: at most 60% for the Musts, a reserve of roughly 20% for the Coulds. This view tells grouping apart from its neighbours at a glance, where ranking would line up a single ordered file and time boxing would start from a fixed-size container.

Cost

Tools

Any requirements management or backlog tool that accepts a custom priority field or label will do, from Jira to Azure DevOps by way of a requirements catalogue or a simple shared spreadsheet. There is no reason to recommend one: what matters is that the band is an attribute of the requirement itself, revised along with it.

The spreadsheet deserves a mention of its own. The effort balance becomes a formula there: a column of estimated effort, a sum per band, a cell that turns red as soon as the Musts' share exceeds 60%. The check the technique demands at each pass then runs on its own, the moment the sort is entered. The same formulas spot the suspicious grades and count how many items each band holds. A backlog tool places the band where the team already reads and versions it, which answers the most ordinary maintenance failure, a priority set once and never revisited. The tool to avoid is the slide: a MoSCoW list in a presentation is the photograph of a trade-off, it does not sort, does not recount and goes stale at the first re-estimate.

Sources

• IIBA, A Guide to the Business Analysis Body of Knowledge (BABOK Guide) v3, §10.33 Prioritization: grouping as one of the four prioritisation approaches, the generic "high, medium, low" example, listing the priority category as an attribute of a requirement, revisiting priorities when changes occur and the acknowledged limits of prioritisation, dodged trade-offs, overstated implementation difficulty and the scarcity of hard metrics. Cited descriptively: BABOK defines neither the MoSCoW categories nor the effort rule.
• Agile Business Consortium, MoSCoW Prioritisation, DSDM Project Framework: the definitions of the four categories, Must have as the minimum usable subset, Should have, Could have as contingency and Won't have this time as a dated deferral, together with the effort balance: a 60% ceiling for Musts and a reserve of around 20% for Coulds. This is the source of every operational rule of MoSCoW.
• Dai Clegg and Richard Barker, Case Method Fast-Track: A RAD Approach, Addison-Wesley / Oracle, 1994: the origin of MoSCoW, coined by Dai Clegg then adopted by the DSDM Consortium. Cited for this single historical fact, the current operational rules belonging to the Agile Business Consortium's present-day publication.