How should we apply MoSCoW prioritization to our project requirements?

Question

I've read a reference to MoSCoW prioritization. I'm confused about what the requirements are for each level:

1. Must Have
2. Should Have
3. Could Have
4. Won’t Have (this time)

Do we need all four levels of prioritization?

Answer 1

TL; DR

The MoSCoW method provides a framework for prioritizing based on bucket-sorting of features. It's meant to be flexible, so you have to customize it for your project. You can tweak the definitions and criteria for each level as needed, and may or may not need to make a distinction between Should Have and Could Have features. However, you most certainly need to maintain a distinction between Must Have, Won't Have, and whatever features are to some extent optional.

Prioritization and Scope

The page you linked to in your original question contains sample definitions and filtering criteria for each level. I won't rehash their perfectly serviceable explanation, but perhaps it will be more clear if you think of it as a scoping exercise.

1. Must Have features are part of the minimum viable product, and must remain within scope.
2. Won't Have (This Time) features are explicitly out of scope for the current project, but might be revisited in future projects.
3. Should Have / Could Have features are in scope, but can be modified or descoped during the project lifecycle because they aren't essential for the minimum viable product.

Definitions and Filtering Criteria for Each Level

The page you linked to in your original question contains sample definitions for each of the levels. In addition, section 10.3 contains guidance on how to define each level for your specific project, and how to determine categorization. It says, in part:

Prior to requirements capture, the definitions of Must Have, Should Have, Could Have and Won’t Have need to be agreed with the business. Some examples are described above. However, the Must Have definition is not negotiable. Any requirement defined as a Must Have will have a critical impact on the success of the project. The Project Manager or Business Analyst should challenge requirements if they are not obvious Must Haves; it is up to the Business Visionary or their empowered Business Ambassador to prove a requirement is a Must Have. If he/she cannot, it is a Should Have at best.

To put it another way, each project must:

1. Go through the exercise of defining each level as it applies to the current project. Definitions can vary between organizations, and even between projects within a single organization unless the organization has created an internal standard.
2. Have stakeholders justify each categorization, especially the Must Have category, based on their business drivers. This will vary based on the goals of the project, and should be assessed within the context of the project's charter.

Answer 2

I believe you need all of them for having a conversation. First, you categorize all requirements, and then review the result and see what can be moved down on the list. After a couple of iterations, you'll have a pyramid of requirements: must on the top, won't have in the bottom. You'll use your resources on the top, and bring the rest to the next discussion.

Keep in mind that the categorization can be done in short and long terms. For example, something now may fall into could have now - an AWS infrastructure instead of a rack solution -, but may become must have shortly - increase in the customer base, need scalability.

Answer 3

I'm preparing for the AEC and CSM, and it would probably help if you see this from a broader Agile perspective.

Domain One of Agile Practices is Value-Driven Delivery. The "Practices for Value-Drive Delivery" include:

• Assessing Value
• Planning Value
• Delivering Value
• and so on...

Planning Value involves "Customer-valued Prioritization" with the intent to get the highest value products or features to the customer first. MoSCoW is just one of many options available to you.

As someone already explained, it's putting your requirement in buckets, or the way the book likes to say "Affinity Groupings" based on exactly those characteristics:

• Must Have
• Should Have
• Could Have
• Would like to Have (but not this time).

It's simply up to you after that!!! Other customer-value prioritization schemes you could use include:

• Simple schemes ("priority 1", "priority 2", etc.);
• Monopoly money (project budget represented with play money and customers allocate some portion of that fixed amount to the features they want most);
• 100-point method (Dean Leffingwell and Don Widrig);
• Kano anlysis (Noriaki Kano's method for grouping into Exciters, Satisfiers, Dissatisfiers, and Indifferent).

So again, it's up to you how you execute it and you have more than just MoSCoW to choose from. :-)