MoSCoW method: explanation, examples and practical use
The MoSCoW method is one of the most widely used prioritisation techniques in software development and project management. By sorting requirements into four clear categories (Must, Should, Could and Won't), it creates a shared understanding among stakeholders, developers and product owners of what truly matters. In this article, we explain how MoSCoW works, where it comes from, and how you can apply it straight away in your own projects.
From Clegg to everyday practice: where does MoSCoW come from?
The MoSCoW method was developed in 1994 by Dai Clegg, then a consultant at Oracle UK. Clegg was looking for a way to classify requirements quickly and unambiguously during software projects with tight deadlines. The method was first formally described as part of the Dynamic Systems Development Method (DSDM), an early agile framework that became especially popular in the United Kingdom and the Benelux.
The acronym MoSCoW stands for Must have, Should have, Could have and Won't have (this time). The lowercase "o"s in the acronym are there purely to make the word pronounceable; they carry no meaning. The addition of "this time" to Won't was a deliberate choice: it signals that a requirement is not being rejected permanently, but is deliberately deferred to a later iteration.
In the Netherlands, MoSCoW has become a standard in requirements engineering and project management. The method is widely used in public-sector tenders, enterprise projects and start-up MVPs. Its popularity stems not from complexity but from simplicity: four categories, understandable to both technical teams and business stakeholders, with no training or tooling required.
Whereas methods such as RICE or Weighted Shortest Job First (WSJF) require specific scores and formulas, MoSCoW relies on a qualitative classification that anyone in a meeting can apply. This makes it particularly well suited to situations where speed and agreement matter more than mathematical precision, such as kick-off workshops, sprint planning and scope negotiations with stakeholders.
The four categories explained: Must, Should, Could and Won't
Every requirement receives exactly one of the four labels. The strength lies in its clarity: there is no middle option, no "almost a must" or "high could". That forces teams to make genuine choices.
Without it, the project fails
Must have requirements are non-negotiable. The project delivers no usable result if they are missing. Examples include legal requirements, core functionality without which the product does not work, or contractually agreed deliverables. A requirement is only a must if the answer to the question "can the product go live without this?" is unequivocally "no". In practice, in app development, musts include, for example, a working authentication system, the ability to process payments in an online shop, or GDPR compliance when handling personal data.
Important, but not blocking
Should have requirements are valuable and almost always delivered, but the product can temporarily do without them. A workaround usually exists. For example, advanced search filters in a product catalogue: the catalogue works without them, but the user experience improves considerably when they are present. Should haves are typically scheduled in the first sprints after the MVP release. They form the bridge between "it works" and "it works well".
Nice to include, not a hard requirement
Could haves improve the experience but are not essential to the success of the project. They are the first items to be dropped when budget or timeline comes under pressure. Think of dark mode, animations on page transitions, or an optional third-party integration. Could haves act as a buffer in the plan: if the team moves faster than expected, they can still be picked up. This prevents developers from sitting idle when things go well.
Deliberately parked, not forgotten
Won't have is the most underrated category. It is not a rejection, but a deliberate scope decision: "we know this is valuable, but we are not doing it now." By placing requirements explicitly under Won't, you prevent scope creep, the gradual expansion of a project that undermines deadlines and budgets. It is also a communication tool for stakeholders: their wish has been heard and documented, but does not fit the current release. A Won't item can be reconsidered in a future iteration or version.
MoSCoW in practice: a requirements session step by step
Applying MoSCoW is not a bureaucratic process. In most cases, a single workshop session with the right stakeholders is enough. Below we describe a proven approach that we regularly use in consultancy engagements and project kick-offs.
-
1Gathering requirements
Collect all known wishes, requirements and ideas without judgement. This can be done through interviews, existing documentation, user stories or a brainstorming session. Each item gets a short, unambiguous description. Resist the urge to filter at this stage: at this point, quantity matters more than quality.
-
2Bringing stakeholders together
MoSCoW works best when different perspectives are represented: product owners, end users, technical leads and business stakeholders. Without business input, prioritisation becomes skewed towards technology; without technical insight, unfeasible items get labelled as must haves.
-
3Categorising together
Go through each requirement and ask the key question: "Can the product go live without this?" If the answer is "yes", it is not a must. Then ask: "Would the user be significantly hindered if it were missing?" If so, it is a should, otherwise a could. Items the group agrees "we'll do that next time" go to won't. Preferably use a visual aid such as a whiteboard, sticky notes, or a digital MoSCoW tool.
-
4Checking the balance
A common rule of thumb is that must haves should not account for more than roughly 60% of the total effort. The reasoning: if all must haves together consume all available budget and time, there is no room for setbacks. The should and could categories act as breathing space in the plan. If the balance is skewed, reconsider whether certain musts are truly blocking.
-
5Adjusting iteratively
MoSCoW is not a one-off exercise. At every sprint review, scope change or new stakeholder input, you recalibrate the distribution. A should may move up to must if user feedback calls for it; a must may drop to could if the market changes. The document evolves with the project.
Common mistakes in MoSCoW prioritisation
MoSCoW is simple in theory, but in practice we regularly see patterns that undermine its effectiveness. Recognise these pitfalls before they affect your project.
-
Labelling everything as Must
The most common mistake. Stakeholders feel pressure to position their requirements as indispensable. The result: a list where everything is "critical" and the team has no direction. If everything is a priority, nothing is a priority. Set a maximum for must haves (for example, 60% of planned capacity) and hold the group to it.
-
Ignoring or leaving out Won't
Teams that skip the Won't category lose their most important weapon against scope creep. Without an explicit "no" list, requests quietly creep into the scope. Document Won't items just as carefully as musts; they are your line of defence when stakeholders raise new requirements halfway through the project.
-
Filled in once and never updated
A MoSCoW prioritisation agreed at kick-off and never revisited soon reflects an outdated reality. Markets shift, user feedback comes in, and technical feasibility becomes clearer. Schedule fixed moments (sprint reviews, phase closures) to recalibrate the prioritisation.
-
Prioritising too technically without business stakeholders
When only the development team runs the MoSCoW session, you get a technically sound but commercially blind prioritisation. The business sees different musts than developers do. A feature that is technically trivial may be commercially crucial, and vice versa. Make sure both perspectives are at the table.
-
No distinction within categories
MoSCoW gives you four buckets, but within each bucket everything is treated as equal. That works for a manageable feature list, but becomes problematic with large backlogs containing dozens of should haves. In that case, consider a secondary ranking within the categories, or combine MoSCoW with a numerical method for finer-grained prioritisation.
MoSCoW versus other prioritisation methods
MoSCoW is not the only way to prioritise requirements. Depending on the context (team size, backlog size, product maturity), another method may be a better fit. Below we compare MoSCoW with three popular alternatives.
| Aspect | MoSCoW | RICE scoring | Kano model | WSJF (SAFe) |
|---|---|---|---|---|
| Core | Qualitative classification into 4 categories | Numerical score: Reach x Impact x Confidence / Effort | Customer satisfaction model: basic, performance, delighter | Cost of Delay divided by job size |
| Complexity | Low: understandable to everyone | Medium: requires data estimates for each factor | High: requires user research | High: requires knowledge of the SAFe framework |
| Best for | MVP definition, scope boundaries, workshops | Large product backlogs, data-driven teams | UX-driven product development | Enterprise agile, portfolio-level prioritisation |
| Weakness | No nuance within categories; subjective | False precision from unreliable estimates | Time-consuming research needed | Overhead; of little value for small teams |
| When to choose | Quick consensus needed, mixed stakeholders | Sizeable backlog, quantitative culture | Product-market fit stage, UX focus | Multiple agile teams, enterprise context |
Combining methods can be valuable
In practice, these methods are not mutually exclusive. A common combination: start with MoSCoW for the rough categorisation during a workshop, then use RICE scoring to determine the order within the should and could categories. This way you combine the accessibility of MoSCoW with the precision of a numerical model.
Applying MoSCoW in agile software development
MoSCoW fits seamlessly into an agile way of working. When drawing up a product backlog, the method helps fill the first sprints with must haves, followed by should haves in later iterations. The could haves form a reserve for sprints that run faster than expected, while won't haves are explicitly kept out of the current release.
In app development projects, we often use MoSCoW during the discovery phase to define an MVP together with the client. The core question is: what must the first version of the application minimally do to deliver value to users? Anything beyond the answer to that question is, by definition, not a must.
This approach prevents one of the most costly mistakes in software projects: building too much in the first release. An overloaded MVP translates into longer lead times, higher costs and delayed feedback from real users. MoSCoW gives you the tools to hold that conversation clearly.
Practical applications per phase
Sprint planning: user stories are tagged with their MoSCoW label. The sprint commitment covers all musts and as many shoulds as possible. Coulds are only included if the velocity forecast leaves room for them.
Scope negotiation: when a deadline is under pressure, MoSCoW gives you immediate footing. The musts are protected; the shoulds and coulds are redistributed across later releases. Without MoSCoW labels, the discussion descends into opinions. With MoSCoW, it becomes a factual conversation.
Stakeholder communication: a one-page MoSCoW overview communicates more than a backlog of a hundred user stories. It gives executives and clients an at-a-glance view of what they will get, what will probably make it in, and what is explicitly out of scope.
Would you like to try MoSCoW on your own requirements straight away? Use our interactive MoSCoW tool to categorise items and assess the distribution visually.
Frequently asked questions about the MoSCoW method
What does MoSCoW stand for?
MoSCoW is an acronym for Must have, Should have, Could have and Won't have (this time). The lowercase "o"s were added to make the word pronounceable and carry no substantive meaning. The method was devised in 1994 by Dai Clegg at Oracle UK as part of the DSDM framework.
When should you use the MoSCoW method?
MoSCoW is most valuable when defining project scope, establishing an MVP, or determining release content. The method works particularly well in situations with multiple stakeholders who need to agree on priorities, such as kick-off workshops, sprint planning sessions, or scope negotiations.
What is the difference between Should and Could?
A should have is important and will be delivered in a normal project course; it has a noticeable impact on the user experience or business value. A could have is desirable but not impactful enough to create a hard expectation. The distinction lies in the consequence of leaving it out: with a should, the user will notice; with a could, they probably won't straight away.
Can Won't have items be added later?
Yes, that is precisely the intent behind the phrase "this time". Won't have does not mean "never", but "not in this release or iteration". Won't haves can be reassessed in each subsequent planning cycle. Some are promoted to could or should; others deliberately remain parked because priorities do not change.
How do you prevent everything becoming a Must have?
Set a capacity ceiling in advance: must haves together should not account for more than roughly 60% of the available project capacity. Require participants to answer the core question: "Does the project fail if this is missing?" Often this phrasing leads to more honest classification. An independent facilitator can help keep stakeholders on track.
Is MoSCoW suitable for large enterprise projects?
MoSCoW works well as a top-level prioritisation method, including at enterprise scale. For the detailed ordering of a backlog of hundreds of user stories, it may be too coarse; consider combining it with RICE scoring or WSJF for fine-grained ranking. MoSCoW's strength lies in quickly creating alignment at the strategic level, not in micromanaging individual tasks.
Which tools exist for MoSCoW prioritisation?
Alongside physical methods (sticky notes, whiteboards), there are various digital tools. Appfront offers a free online MoSCoW tool with which you can categorise items straight away and assess the distribution visually. In addition, project management tools such as Jira, Azure DevOps and Notion support custom labels, allowing you to assign MoSCoW tags to user stories.
Start your project with clear priorities
A well-prioritised project delivers results faster, stays within budget and avoids debate halfway through. We help you structure requirements and build software that does what it needs to do, from app development to consultancy.
The MoSCoW method is often used to sharpen the scope of an MVP; see also our guide to what an MVP is.