What is the 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:

How to use the MoSCoW Method in a workshop setting

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

  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. 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. 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.