Skip to content

MoSCoW Prioritization

The MoSCoW technique is used by analysts and stakeholders for prioritizing requirements in a collaborative fashion.The letters stand for:

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

The MoSCoW rules

Must Have

These provide the Minimum Usable SubseT (MUST) of requirements which the project guarantees to deliver. These may be defined using some of the following:

  • No point in delivering on target date without this; if it were not delivered, there would be no point deploying the solution on the intended date
  • Not legal without it
  • Unsafe without it
  • Cannot deliver a viable solution without it

Ask the question ‘what happens if this requirement is not met?’ If the answer is ‘cancel the project – there is no point in implementing a solution that does not meet this requirement’, then it is a Must Have requirement. If there is some way around it, even if it is a manual and painful workaround, then it is a Should Have or a Could Have requirement. Categorising a requirement as a Should Have or Could Have does not mean it won’t be delivered; simply that delivery is not guaranteed.

Should Have

Should Have requirements are defined as:

  • Important but not vital
  • May be painful to leave out, but the solution is still viable
  • May need some kind of workaround, e.g. management of expectations, some inefficiency, an existing solution, paperwork etc. The workaround may be just a temporary one
  • 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, measured in terms of business value or numbers of people affected.

Could Have

Could Have requirements are defined as:

  • Wanted or desirable but less important
  • Less impact if left out (compared with a Should Have)

These are the requirements that provide the main pool of contingency, since they would only be delivered in their entirety in a best case scenario. When a problem 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

These are requirements which the project team has agreed will not be delivered (as part of this timeframe). They are recorded in the Prioritised Requirements List where they help clarify the scope of the project. This avoids them being informally reintroduced at a later date. This also helps to manage expectations that some requirements will simply not make it into the Deployed Solution, at least not this time around. Won’t Haves can be very powerful in keeping the focus at this point in time on the more important Could Haves, Should Haves and particularly the Must Haves.