MoSCoW method: how to prioritize requirements after a meeting

Priority depends on the goal and time frame

At the meeting, everyone called their feature mandatory. A list like that will not help set the scope. First agree on the outcome the next release must deliver and what would make it unusable. Priorities can be completely different in another phase.

MoSCoW has four categories: Must Have, Should Have, Could Have and Won’t Have this time. The last one deliberately excludes a requirement for the period under discussion. It does not promise delivery later or rule the idea out permanently.

Discuss the consequences of leaving things out

1. Describe the release goal

   Identify the user, the task and the conditions of use. Clarify the constraints and planning horizon. If the goal is just “improve the product,” people will apply different criteria and label almost everything mandatory.

2. Test Must candidates

   For each candidate, ask whether the result would be usable without it. Consider acceptable workarounds and dependencies. A mandatory requirement needs a concrete rationale. “The manager asked for it” identifies the source but does not explain what would happen without it.

3. Distinguish important from desirable

   A Should is important: the result is noticeably weaker without it but still usable. A Could is a useful addition that is easier to leave out. Explain the difference in terms of the user’s task and the cost of omission, beyond phrases like “we really need it.”

4. Agree on exclusions and when to revisit them

   For a Won’t in this period, record the reason and the condition that would reopen the discussion. Check dependencies and whether the selected scope is feasible. If mandatory work exceeds capacity, revisit the scope or the plan. Relabeling items does not solve a capacity problem.

First release of an event registration form

This is a fictional training example. The names, circumstances and outcomes are included solely to explain the method.

In this example, the goal is to register a participant and give them a clear confirmation. Submitting an application is a Must because the main task cannot happen without it. A reminder may be a Should if the team can use an agreed workaround for now.

Badge color can be a Could, and a personal account can be left out this time. These are specific to this event. The consequences would differ for another event or audience.

Priority rationale card

Keep the reasoning as well as the category. That makes it easier to revisit the decision when conditions change.

Release / period / goal:
Requirement:
User scenario:
What happens without the requirement:
Acceptable workaround, if any:
Dependencies:
MoSCoW category:
Rationale:
Who confirmed the decision:
When to reconsider:
Exclusions for this period:

Check whether the list helps the team make choices

• The goal and time frame appear next to the categories.
• For each Must, the consequences of omitting it are described.
• Any temporary workaround has been evaluated explicitly.
• Won’t this time is understood as a current exclusion.