How MoSCoW can help streamline your next software project?

MoSCoW is a prioritisation technique used by agile teams to understand the relative importance of project requirements. Prioritisation can be applied tasks, user stories and testing criteria but is mainly used to list and prioritise requirements.

So what does MoSCoW stand for:

  • Must Have
  • Should Have
  • Could Have
  • Won’t Have this time

At Wolf Logic we use MoSCoW instead of simpler prioritisation techniques as it provides greater definition to product requirements and focusses discusion. This is particulary useful for building minimum viable products (MVPs).

Here are the MoSCoW Rules…

Must Have

These provide the minimum requirements which the project guarantees to deliver. These may be defined using some of the following:

  • The project can’t be deployed without these
  • Does not meet acceptable standards or certification
  • Is missing core functionality

Note: Ask the question ‘what happens if we don’t meet this requirement?’ If the answer is ‘Its a show stopper’, then it is a ‘Must Have’ requirement. If not then it is a ‘Should Have’ or a ‘Could Have’ requirement.

Should Have

Should Have requirements are often the most difficult to define as often there is a fine line between making the ‘Must Have’ category. They are defined as:

  • Important but not vital
  • May be difficult to leave out, but the solution is still acceptable

Note: One way of differentiating a ‘Should Have’ requirement from a ‘Could Have’ is by reviewing the degree of pain caused by the requirement not being met and measuring in terms of value to the business or individuals affected.

Could Have

Could Have requirements are defined as:

  • Wanted or desirable but not as important
  • Low impact if left out when compared to a ‘Should Have’

Note: When an issue occurs and the deadline is at risk, one or more of the ‘Could Haves’ provide the first choice of what is to be dropped from this timeframe.

Won’t Have this time

Often this category includes future stages of the product road map. Its important to list these requirement to clarify the overall scope of the project.

‘Won’t Haves’ can be very helpful in keeping the focus at this point but they do provide an opportunity to list every requirment from early discussions so features or functions don’t get ignored.

Note: This helps to manage expectations that as some requirements will simply not make it into the deployed solution at least not this time around.

Need to

If you would like any advice or help defining your software product requirements then please get in touch and speak to our team.