MoSCoW Method

Developed in 1994 by former Oracle consultant Dai Clegg, the MoSCoW Method is a product management tool used to help development teams prioritize their product backlog.

This exercise, like User Story Mapping, provides a clear framework for approaching and iterating different versions of the same product through the lens of: 1) targeted user needs, 2) technical constraints (i.e. security, reliability) or 3) internal constraints (i.e. industry regulations, organizational dependencies).

Simple to set up—and particularly useful for managing projects faced with time or resource limitations—the MoSCoW Method has product development teams rank product features and functionality across four key priority areas:

• M = “Must Have”
  These features must be implemented to meet foundational user expectations or overcome primary product safety or reliability constraints.
• S = “Should Have” (if feasible)
  These features differentiate a new product from other competitor products. Although these features offer clear end-user value, they are not absolutely essential to launch a product and, thus, are less urgent to implement in the near-term.
• C = “Could Have” (if it does not affect anything else)
  These features can make a marked impact on the commercial success and viability of a product and should be implemented—but only if the product development team has the time to implement them without affecting other must-have features. Looking at this in another way, if a project is already behind schedule, these features can be sacrificed in the near-term to ensure the timely delivery of a less comprehensive version of the product.
• W = “Would Like to Have” (but not at this time)
  These features are not essential in the near-term and will likely be addressed in future iterations of a product. Of course, should product or user priorities evolve, these features could easily move up in the order of priorities at any time.

The MoSCoW method workshop typically is broken down into three key stages:

1. 1. Identify tasks to be completed

   The product team gets together to brainstorm all the outstanding tasks related to the successful delivery of a new product. There is no need to put them in any priority order at this time; the goal at this stage is simply to make sure all tasks are in plain sight for everyone to see. As part of this exercise, the team should ask:

   • Can some larger features be broken down into several smaller features?
   • Can some smaller features be grouped together? (This is especially important for features that cannot be developed independently of one another)
   • What are the internal or external dependencies to be taken into account?

2. 2. Prioritize tasks

   Now that you’ve listed out all of the tasks to be completed, it’s time to prioritize them in one of the four categories mentioned above. To reiterate:

   • What features are essential for launching a functional and attractive product?
   • What features are essential but less urgent at the present time?
   • What features can be developed only if time permits?
   • What features can be put on the ‘back burner’ for now and reprioritized later?

   Prioritizing various product-related tasks in this way forces teams to make thoughtful trade-offs and eventually reach consensus—either by vote or via pre-determined scoring criteria—around what is truly needed to launch a version of a product that meets primary user needs and expectations. In the end, this part of the workshop is about identifying the essential tasks that strike the right balance on the basis of business value versus task complexity.

3. 3. Validate the prioritization

   It’s very easy to identify a large number of tasks as essential, especially taking into consideration the various objectives and priorities of different stakeholders participating in the workshop. However, the goal here should always be to get the list of “Must Have” tasks as concise as possible. This requires full team alignment around what is absolutely essential for launching a well-functioning product at any stage of its development. Oftentimes this requires key decision-makers to validate the results of the workshop, which can also help remove obstacles or other organizational dependencies hindering progress.