MoSCoW Method of Prioritization explained

Article by: Patty Mulder

Last update: January 28, 2026

MoSCoW Method: This article explains MoSCoW Method in a practical way. Next to what it is (meaning, acronym and origin), and which advantages are connected to using this model, this article also highlights the MoSCoW Method requirements, including a practical example. You will also learn how applying this method will enable you and the team to reach deadlines in time. Enjoy reading!

What is the MoSCoW method and when do you use it?

Setting priorities is difficult for many organizations. Especially when it comes to new ideas, projects, or technologies, everything seems important and everyone wants to implement everything at once. In practice, this is impossible. Time, budget, and capacity are limited. That is precisely when you need a simple, collaborative way to make choices. The MoSCoW method is one of the most commonly used techniques for doing this in a structured way.

The MoSCoW method is a prioritization technique for requirements and wishes within a project or development process. The name is an acronym. The letters M, S, C, and W stand for Must haves, Should haves, Could haves, and Won’t haves or Would haves. The two o’s were added solely to make the word MoSCoW easy to read and have no meaning of their own. By placing each requirement in one of these four categories, it becomes clear what is absolutely necessary, what is important, what is “nice to have,” and what is deliberately outside the scope for the moment.

The method was developed by Dai Clegg at software company Oracle. It originated in software development, where project teams often work with long wish lists, many stakeholders, and tight deadlines. MoSCoW allows them to determine which functionalities are minimally necessary for a first version or release and which wishes can be postponed to a later phase.

In practice, MoSCoW is more widely applicable than just IT. The method works just as well for market introductions, product launches, setting up a new company, change processes, or internal improvement projects. Wherever there is a set of requirements and wishes and not everything can be done at once, MoSCoW helps to make tough choices.

The core of the MoSCoW method is the total package of requirements in order of priority. The Must haves form the lower limit. Without these requirements, the project or product has little chance of success. Should haves provide clear added value, but are not strictly necessary to go live. Could haves are nice if there is still room. Won’t haves explicitly state which wishes are deliberately not included at this stage. This creates a realistic picture of what is minimally required and where there is flexibility, which greatly increases planning, communication with stakeholders, and the chance of success.

Figure 1 – the MoSCoW Method acronym

MoSCoW method as a set of requirements and approach

Before starting with the MoSCoW method, it is recommended to first specify the set of requirements.

When drawing up the requirements, as much consideration as possible should be given to what stakeholders consider important. Brainstorming with those involved can ultimately result in good quality requirements.

To prevent unrealistic or very expensive requirements from being set, they are listed in order of priority. The main focus is on which requirements will deliver the most added value for the company. The project requirements are classified into one of the following categories:

M – Must-haves

This refers to the minimum set of requirements that are set in advance and that the end result must meet. Without these requirements, the project will fail and the product will no longer be usable. They are required for a workable product and there is no alternative.

The Must-haves are essential. MUST is also explained as the acronym for Minimum Usable SubseTs.

Example: HBO Automotive students have to design and build a car as their final exam assignment, which must at least be able to drive (minimum requirements). It is not a problem if there is only a chassis, without a body.

The focus is on the construction of individual parts and the drive to the combustion engine. In this case, the must-have is that the car must be able to drive at the end of the academic year.

S – Should-haves

These are additional and highly desirable requirements that are a high priority but are not essential for a usable end product.

Even if these requirements are not met, the product is still usable, and meeting them only adds value to the product. Depending on the time available, these requirements can always be addressed later.

Example: The HBO Automotive students may want to equip the car with a tow bar (should-have), but if the car can drive without the tow bar, their project is still a success. They can still install the tow bar at a later stage.

C – Could-haves

If there is time, these requirements can always be addressed. If not, it is not a problem and will not have a negative impact on the end result. The could-haves have less priority than the should-haves. The option will only be included if there is really enough time to realize it. It is also referred to as “nice to have” and is more of a wish than a strict requirement.

Example: The HBO Automotive students may wish to install a tachometer in the car. This is not an important (exam) requirement, but it would be nice if they succeeded.

W – Won’t-haves (and would-haves)

These are future wishes that are often impossible or take a lot of time to realize. If they are not possible, it is wise not to put any energy into them.

If realization is possible, a lot of time (and money) will have to be invested, and it is considered a would-have. Would-haves are often included in a follow-up project.

Example: For HBO Automotive students, it is not necessary for the car to actually drive on the road. It is a study object. If it is still a wish to drive on public roads, the car must be fitted with a body and meet safety requirements. Permission must also be requested from the Road Transport Agency (RDW) through a lengthy process.

The MoSCoW Method and deadlines

When the MoSCoW method is properly applied and enforced, it provides a clear way to manage a project.

Every participant in the project knows what needs to be done first, within what timeframe, and why. Assigning priorities to requirements makes a project manageable and speeds up progress toward the deadline.

By temporarily leaving out the less important requirements, the development and support of a project is also simplified. By focusing on the key conditions, a marketable product is created that meets the minimum requirements. In this way, must-haves also become unique selling points that benefit the customer.

How do you conduct a MoSCoW session?

The MoSCoW method works best when implemented together with the most important stakeholders. Below is a practical step-by-step plan that can be applied directly in a project or workshop.

Step 1. Gather all requirements and wishes

Start by creating a single, clear list of all requirements, user stories, demands, and wishes. Don’t evaluate anything at this stage, just gather information. You can do this through interviews, a short questionnaire, or a joint brainstorming session.

Step 2. Make sure the right people are at the table

Invite people who have an interest in the outcome. Think of the client, product owner, user representatives, IT, or operations. The better the group knows the practice and the impact, the stronger the priorities that emerge.

Step 3. Agree on the categories and criteria together

Briefly explain what Must haves, Should haves, Could haves, and Won’t haves mean. Make this concrete with one or two examples from your own project. Then agree on criteria. For example, Must haves are requirements that are necessary to go live or to comply with legislation and safety regulations. Anything that does not fall under this category should be classified as at least Should or lower.

Step 4. Assign each requirement to a category

Go through the list systematically and determine which category each requirement falls into. Always have one person make the initial assessment and then briefly discuss whether the group agrees. Avoid lengthy discussions. If there is doubt between Must and Should, ask what will happen if this requirement is not met in the first delivery.

Step 5. Reassess if there are too many Must haves

In practice, it often happens that the list of Must haves becomes too long. If this happens, go through the Must category again. Critically reassess whether these requirements are really necessary to make the project result usable and acceptable. A firm agreement helps with this, such as a maximum percentage of the total effort that can be included in Must.

Step 6. Record the outcome and link it to the planning

Put the final classification in an overview that everyone can find. Use the Must and Should haves as the basis for scope, planning, and capacity. Could haves come into play if there is room left over. Won’t haves become explicit as maybe later, but not now. Refer to these agreements in communication so that it is clear why certain wishes have been included and others have not.

Step 7. Update when changes occur

Projects and environments change. Therefore, schedule fixed moments to review the MoSCoW classification, for example at the start of a new phase or release. New requirements can then be added and existing requirements can change categories if the situation requires it. This way, MoSCoW remains a living document instead of a one-time exercise.

Pitfalls when using the MoSCoW method

The MoSCoW method seems simple, but in practice there are a number of recurring pitfalls. By being aware of these in advance, the outcome of a session will be much stronger and more defensible to stakeholders.

The first pitfall is that almost everything ends up in the Must category. Many stakeholders see their own wishes as indispensable. If this is not managed, an overloaded package of requirements will still be created and MoSCoW will lose its power. It helps to agree on a maximum percentage for Must haves in advance or to always ask what exactly will go wrong if this requirement is missing in the first delivery. If the product or project is workable and acceptable without this requirement, it belongs more in the Should or Could category.

A second pitfall is the lack of clear criteria. If the terms Must, Should, Could, and Won’t are only explained in general terms, the discussion quickly becomes based on gut feeling. One person calls something a Must because customers consider it important, another because it is technically useful. Therefore, agree on specific criteria in advance. Must haves, for example, are requirements that are necessary to go live, comply with legislation, or guarantee a minimum quality. Should haves are requirements that add a lot of value but can be temporarily postponed.

A third pitfall is that MoSCoW is seen as a one-time exercise. Priorities are not set in stone. New insights, changing legislation, or feedback from the market can shift the classification. If the classification is not reviewed regularly, the overview becomes outdated and the document loses its credibility. It is therefore wise to briefly review the MoSCoW classification at the start of a new phase, release, or major change.

A fourth pitfall is that the outcome is not linked to planning and capacity. This creates the risk that MoSCoW will remain a neat table in a document, with no impact on reality. The strength of the method lies precisely in its translation into scope, lead time, and deployment of people and resources. Must-haves and should-haves must be reflected in planning, budgeting, and resourcing. Could-haves are only addressed if there is room for them. Won’t-haves are deliberately not planned for, and this is also communicated.

Finally, there is the risk of insufficient involvement of the right people. If only an internal project team makes the classification, without the client or users, this will lead to discussion afterwards. In any case, involved stakeholders must provide input and preferably participate in the prioritization. This takes time up front, but prevents many misunderstandings and scope discussions later on.

By consciously avoiding these pitfalls, the MoSCoW method becomes a powerful tool for setting transparent, substantiated, and joint priorities in projects and changes.

MoSCoW in combination with agile and project planning

The MoSCoW method fits in well with agile working. In an agile environment, there are often long backlogs of user stories, wishes, and ideas. By applying MoSCoW, it becomes clear which stories should be included in the next sprint or release and which can wait. Must haves then form the basis for a minimum viable product or MVP. Should and Could haves provide scope to add extra value as soon as capacity becomes available.

In traditional project planning, too, the MoSCoW method is a practical link between requirements and planning. First, the requirements are prioritized, then it is determined how many Must and Should haves fit within the available budget and lead time. This way, scope does not become a vague list of wishes, but a concrete and achievable package. This link helps to deploy time, money, and people in a targeted manner and prevents a project from becoming unrealistically large along the way.

MoSCoW can be easily combined with other project management tools. The Must haves are aligned with the critical success factors and the minimum result specified in a project mandate or business case. Should and Could haves can be phased into a roadmap or release schedule. Risk analyses and stakeholder analyses provide additional input to help make a decision when in doubt. In this way, MoSCoW becomes not just a separate list, but an integral part of how projects are planned, managed, and adjusted.