The MoSCoW prioritization method for Business Requirements

The MoSCoW method is a prioritization technique used in project management to categorize business requirements into four categories: Must have, Should have, Could have, and Won’t have. This allows business to prioritize which project requirements provide the best return on investment (ROI).

1. Must have: These are the essential requirements that are critical for the success of the project. They are non-negotiable and must be delivered in order for the project to be considered successful.
2. Should have: These requirements are important but not critical for the success of the project. They are considered high priority and should be included if possible, but can be deferred to a later phase if necessary.
3. Could have: These requirements are nice to have but not crucial for the success of the project. They are considered low priority and can be included if there is time and resources available, but can also be deferred to a later phase or dropped altogether.
4. Won’t have: These requirements are not included in the current scope of the project. They may be considered for future phases or projects, but are not part of the current deliverables.

When distributing requirements into MoSCoW categories, several factors should be considered, including:

• Business value,
• Impact on stakeholders,
• Time sensitivity,
• Resource availability,
• Dependencies,
• Risks and constraints,
• Alignment with strategic goals.

How to Apply

To apply MoSCoW method, firstly, identify and list all the business requirements for the project. Categorize each requirement into one of the four categories. Work with stakeholders to validate and finalize the categorization of the requirements. Then use the prioritized list of requirements to guide project planning and decision-making.

Focus on delivering the must-have requirements first, then move on to should-have and could-have requirements as time and resources allow. Continuously review and update the prioritization of requirements as the project progresses and new information becomes available. Communicate the prioritization of requirements to all project stakeholders to manage expectations and ensure alignment on project scope and deliverables.

By using the MoSCoW method, businesses can prioritize their requirements and focus on delivering the most important features first, while also providing flexibility for including additional features as time and resources allow. This method helps to ensure that the most critical needs are met while also managing stakeholder expectations and project scope.

Prioritization for Incremental Software Delivery with MoSCoW

The iterative and incremental software development approaches such as Agile, DSDM, and Scrum, have become increasingly popular in organisations in recent years, for a number of reasons, including:

1. The need for organisations to respond quickly to fast-changing business situations;
2. The difficulty – indeed, sometimes the impossibility – of knowing what is wanted at an early stage of a project;
3. The importance of flexibility when deciding how a requirement will be delivered. For example, a requirement to protect certain areas of the data may be defined, but there might be several possibilities as to how this is achieved. The solution to deliver this requirement may be decided through an exploration of various mechanisms.

Prioritisation is vital for an incremental delivery lifecycle. Clearly, if all the requirements are deemed to be of equal importance, there is no real way of determining what should go into each work package or iteration. It is here that a prioritisation scheme such as MoSCoW structure is particularly relevant. MoSCoW prioritisation allocations are related to the development and delivery as follows:

• ‘Must have’ requirements will make up the first deployed increment. If an iterative development approach is used, these requirements will form the first elements of the prototypes.
• ‘Should have’ requirements provide one of the mechanisms for introducing contingency and flexibility. The acceptance that they could be implemented as manual workarounds in the short term is extremely helpful when deadlines are tight. Any of these requirements that have not been delivered in the first release will be allocated become ‘must have’ in the second increment.
• ‘Could have’ requirements are often included in the set of requirements under development, particularly if they are relatively easy and inexpensive to incorporate with the higher-priority requirements. Should the development team run out of time, they can be left out.
• ‘Want-to-have-but-not-now’ requirements will be set aside and considered during one of the later increments. They will be allocated a different priority once the moment arrives for their delivery to be considered. For example, there may be a specific date when some of these requirements become mandatory.

The MoSCoW approach is also extremely useful for prioritising business changes. For example, when developing process documentation we can identify the elements that must be included at the outset, those that can wait for the next version and those that could be dropped if we run out of time.