How to Prioritize Product Backlog Using MoSCoW Technique | David Tzemach

MoSCoW method, developed by Dai Clegg, is a broadly used prioritization technique in software development. The main principle of this method focuses on setting requirements by a specific order of priority. The most important requirements (stories) need to be met first to provide the most significant possibility of success and higher business value.

Using this technique, you categorize your list of requirements into the following groups:

Must-haves: The most vital things you cannot live without

“Must have” is considered the minimum requirements essential to the delivery within a specific timeframe and are not negotiable. These are the minimal usable subsets of the product that must be delivered. Without meeting this subset, the product is considered a failure.

Factors that typically categorize these requirements are as follows:

• Failing to meet critical requirements, such as a security issue that makes it insecure for their environments.

• Failing to meet an explicit requirement requested by the customer.

• The product is unsafe for deployment in the customer environment.

• The product fails to function in its core flows.

• There is no point in delivering the product without it.

• The product fails to meet any legal or regulatory criteria (as applicable).

If you still haven’t got it yet, ask yourself what happens if a specific requirement is not met?’ if the answer is ‘We cannot deliver the product to the customer without it’ – then it is a must-have requirement. Suppose you can deliver the product with some workaround to meet this specific requirement acceptable by the customer. In that case, the story can be categorized with a lower priority, such as “Should Have” or “Could Have.”

Should-haves: Things that are important but not vital

Unlike must-haves, these are additional and desired requirements with a high value. However, they are not critical for a usable product or are less important for the current delivery date, even though they can add value. Without delivering these requirements, the product will still be usable. Once added, they will provide additional value to an existing functional system. The factors that typically categorize these requirements are as follows:

• The degree of pain of not delivering this requirement from a business/customer's eyes is reasonable (it’s always subjective in the eyes of the decision-maker).

• It is an essential requirement but not vital to the business/customer.

Could-haves: The nice-to-haves

The ‘could haves’ have a lower priority than the ‘should-haves.’ These requirements are what I refer to as ‘nice-to-have.’ These items are typically done if there is remaining time for the team to work on them once they have completed the ’must’ and ’should-haves. These requirements can improve the customer experience but are not as important (There is no significant impact on customer experience if left out).

Won’t have: All the things that add little value

These requirements represent ‘wishes’ or any ‘enhancements’ that may improve the overall experience. However, they are usually not worth the time, effort or cost needed to deliver them. If it’s not worth it, there is no need to waste any energy on it. To avoid any misunderstanding, it is essential to understand that ‘won’t-have’ requirements of the current sprint can become could and should items for the next sprint.