Software development and the MoSCoW method

Starting a new software development project is daunting. All too often, there’s too much to do and not enough time or resources to do it in. It’s difficult to know where to start, or which features you should be focusing on.

That’s where prioritisation techniques, such as the MoSCoW method, come in. It sorts your ideas and product requirements by importance. This provides a clearer view of what to focus on. The end result (when done properly) is delivering usable software on time and on budget.

So, what exactly is the MoSCoW method, and how can you apply it to your software development?


What is the MoSCoW method?

The MoSCoW method is a prioritisation technique for managing requirements during product development. It stands for four categories of importance:

  • M ust have
  • S hould have
  • C ould have
  • W on’t have

Using MoSCoW is a way to generate a shared understanding of the importance held by each feature of your new software. This clarifies where you need to focus your time and resources.

So, you can keep your software development on schedule. For this reason, the MoSCoW method is particularly useful in agile software development.


Must have

At the top of the MoSCoW method priority list are your must-haves. Must-haves comprise the core functionality and features of your software. They’re the components of your MVP (minimum viable product).

As such, must-haves are non-negotiable functions. Without them, there’s no point in deploying the software. You can identify them by asking a few key questions.

Without this feature, will the program function?

If the answer is no, then the feature is core to your software and is a must-have.

What happens if this feature is not included?

Must-have features make your software usable as well as functional. So, will your target audience be able to use your program without the feature?

Is there a workaround or simpler way to do this?

If the answer to this is yes, it’s likely that the feature is not a must-have. The workaround, meanwhile, may serve as a must-have in its place.


Should have

Should-have features come in close second on the priority list. These are features which are essential for your program, but not a critical component for base functionality.

In other words, your software will work without them but will suffer for their absence.

Should-have features add significant value to your software. So, you can identify them by considering the impact of not having the feature or function.

If it breaks the product — or renders it unusable — it’s a must-have. If the program will work but feel the loss of the feature, it’s a should-have.

Must-have and should-have features should take up about 80% of your development time and focus.


Could have

Next on the priority list laid out using the MoSCoW method are the could-have features.

Could-haves are your nice-to-have features and fixes. They’re wanted. They could improve the user experience or customer satisfaction with your software. But they aren’t needed. So, leaving them out of your next delivery won’t have much of a negative impact.

Could-haves are the first group in the MoSCoW method that can miss your delivery without hurting the user experience. As such, you should only work to include could-have features in your delivery if time and resources permit. That is, after the must-haves and should-haves are complete.  


Won’t have

The final category of features in the MoSCoW method is the wont-haves. Won’t-have features fall into two subcategories: ‘won’t have this time’ and ‘will never have’.

Won’t-have features are the ones that provide the least return on investment. Not having them does not impact your software in any way. In some cases, including them might even hurt the user experience (due to a cluttered user interface.)

The ‘W’ of the MoSCoW method is sometimes considered ‘Would-have’. Would-have features are those that fall only under the ‘will not have this time’ category. They still rank lower in priority than the could-have features.

Whether you view them as ‘won’t-haves’ or ‘would-haves’, the features and functions in this category don’t get time or resources. They’re either dropped or saved for a future development timeline.


The MoSCoW method

The MoSCoW method, in short, helps you keep your projects on schedule. It makes clear where the value of your programming lies, and it helps you avoid feature creep.

So, could you make use of the MoSCoW method in your next software project?


Useful links