What is the MoSCoW Method?

Learn how the MoSCoW method simplifies prioritizing project tasks with clear, actionable categories for better decision-making.

Ceyhun Enki Aksan Entrepreneur, Maker

Sep 15, 2025

To effectively manage resources and minimize potential drawbacks encountered during the process, I am covering various topic headings under the afaik category.

Previously, I briefly mentioned the brief process, an important part of communication between the client and the vendor, and the objectives. In this article, I will discuss the MoSCoW method, a technique (or matrix) similar to the RICE method, which enables the effective prioritization of tasks and project and/or product requirements as a solution to business and resource management challenges.

MoSCoW Method

The MoSCoW method (also referred to as a technique or matrix) is based on the principle of grouping prioritizations within an event sequence under specific categories. In project planning, business processes, product features, and many other objectives, requirements are typically ranked from most to least important. This method was developed in 1994 by Dai Clegg, an Oracle consultant, for use in the Rapid Application Development (RAD) process, and later expanded in a more comprehensive form through the Dynamic Systems Development Method (DSDM) starting in 2002¹. It is commonly used in conjunction with timeboxing².

In processes where resources are limited, requirements are uncertain, and stakeholders have differing responsibilities, the MoSCoW method enables clear identification of project planning, business analysis, and product development, allowing all parties (vendor, client, user, etc.) to clearly understand the scope. Topics from an acquired brief can also be placed into the appropriate four categories of this table, resulting in a clearer and more structured presentation.

The requirements are deferred until they are evaluated under the MoSCoW framework, ensuring that topics are more effectively organized.

Is everyone aware of the project objectives, the core functionalities of the product or service, and the allocated resources for the project, product, or service?
Are the relevant features the stakeholders’ requests or their needs?
What risks affect the delivery of the project, product, or service?
Are responsible persons/decision-makers identified for the defined essential requirements?

Following this assessment, the requirements are evaluated under the following four categories:

Must Have (Required / First Priority)

The scope of the project and the core features of the product are defined under this category³. The sub-items listed here are essential and have the highest priority and certainty, ensuring completion within the specified deadline. If any of these sub-items are not completed, the project is considered incomplete. These sub-items must not conflict with each other or with other priorities. Typically, they require more than 60% of the total effort.

Should Have (Important / Second Priority)

After the completion of the core functionalities of the project and/or product, the secondary tasks that stakeholders have not specifically identified as critical are included under this category. Failure to complete these tasks does not affect the success of the product or project. Typically, these tasks require approximately 20% of the total effort.

Could Have (Good to Have / Third Priority)

Tasks that, if implemented, would enhance customer satisfaction and positively impact the effectiveness of the project and/or the usability of the product are listed under this category. These tasks are considered secondary and are considered for implementation only after the completion of the primary and secondary priorities, based on remaining resources. These tasks do not affect the delivery of the project or product. It is essential that these tasks do not conflict with the first and second-priority tasks.

Won’t Have (Will Not Have / Fourth Priority)

Items that have not been actively assessed within the evaluation scope, do not directly impact the product or project workflow, are currently evaluable for the next development plan, and/or would not jeopardize project success if removed, and have low value (typically aesthetic improvements, etc.) may be considered under this priority. The requests listed here generally fall outside the scope of the product or project delivery.

E-commerce Website Example

Let’s evaluate all the above points within a concrete example context⁴ ⁵.

One issue I frequently encounter involves the uncertainty among brands planning to implement e-commerce online sales regarding the systems they will use. We can examine options such as native e-commerce platforms like WooCommerce and Shopify, evaluated based on required features.

Displaying products
Creating detailed product pages with product attributes (color, size, variations, etc.)
Adding products to the cart
Credit card payment option
Supplier integration
Usage of discount coupons for products and/or orders
Tracking the order fulfillment process
Tracking shipping for specific orders
Integrations with different suppliers
Adding products to favorites
Various payment method options (cash on delivery, PayPal, etc.)
Ability to request support for specific orders

We have listed the features we believe are necessary for an online product offering. But what about our resources? How much time and budget do we have? How many units are we planning to sell? What are our daily sales targets? Answers to these questions will guide the development, supply chain, and operations processes. In situations where resources are limited, time is scarce, and stakeholders are not aligned, the project risks falling out of control.

The features mentioned above are particularly essential for a basic e-commerce website. Therefore, we must have reasons—distinct or specific—justifying a customized solution instead. Otherwise, pre-built solutions would be more practical for effectively utilizing available resources. Now, what are the pros and cons of pre-built solutions? For instance, subscription fees, server response time, theme performance, technical support, and other advantages and disadvantages?

Requirements	Must	Should	Could	Won’t
Product listing	X
Creation of detailed product pages containing product attributes (color, size, variations, etc.)	X
Adding products to the cart	X
Option for visitors to complete payments		X
Payment option via credit card	X
Alternative payment methods (cash on delivery, PayPal, etc.)		X
Supplier integration		X
Usage of discount coupons for products and/or orders		X
Sending birthday messages and discount codes to customers				X
Tracking the order fulfillment process		X
Tracking shipping for specific orders		X
Integration with different suppliers		X
Adding products to favorites		X
Creating support requests for specific orders		X
Delivery option from the weekend			X
Subscription-based payment option			X
Sending browser notifications			X
Product listing via image recognition			X

All of these questions should be evaluated in parallel by stakeholders. Therefore, priorities should be established in relation to the available resources. Of course, additional topics and/or features that are not identified in the initial evaluation phase may also be included in the prioritization process. However, once the prioritization has been approved by stakeholders, it cannot be revised, and transitions between items and/or headings cannot occur during the tracking of the prioritization process.

Of course, besides MoSCoW, other solutions are also available; RICE (Reach-Impact-Confidence-Effort)⁶, Story Mapping⁷, PRiX, and methods developed from the MoSCoW approach for daily use, such as ToToTo (Today-Tomorrow-Tonight) ⁸ ⁹ ¹⁰.

*[afaik]: as far as I know
*[RAD]: Rapid Application Development
*[DSDM]: Dynamic Systems Development Method

Interaction Design Foundation

Member Zone