MoSCoW Analysis

Viewing content for: 

ℹ️Summary

Prioritise your work with Must have, Should have, Could have, and Won't/Would have tasks.

During the analysis phase, it is likely that you have now had contact with a client, and have created a clear set of requirements for your project. At this stage, it is now important to rank these requirements in terms of their prioity. At Level 5, we expect that you should be using the MoSCoW method to do this, this document will provide you with information on what the MoSCoW method is, and how to use it effectively in your projects.

What Is The MoSCoW Method

MoSCoW stands for must, should, could and would:

M - Must have this requirement to meet the business needs

S - Should have this requirement if possible, but project success does not rely on it

C - Could have this requirement if it does not affect anything else on the project

W - Won’t be included in this delivery, sometimes used as Would like to have this requirement later.

The o’s in MoSCoW are simply used to make the acronym pronounceable and don’t actually stand for anything, thus are shown in lower case. The method is used to decide an order of which requirements to complete first, which must come later, and what else could be added but excluded in the delivery. It’s important to clarify why each requirement has been given it’s priority.

Priority of Requirements

Must requirements are non-negotiable. Failure to deliver even one of them will likely mean the project has failed and therefore must be prioritised and completed first.

Should requirements must be completed later, the team should aim to complete as many of these requirements as possible.

Could requirements are requirements that do not affect the overall success of the project, however if you have time and budget, they would be nice to impliment, and as many of them should be implimented as possible, without affecting anything else on the project.

Won’t requirements are not essential to the projects success but would be nice to have in future releases. These should be the lowest priority, and along with Could requirements, should be the first to go if the timeline or budget comes under pressure.

These are based on reference [1].

How to Identify Must Requirements

A lot of the time, the client will specify which requirements they want prioritising first. If they do not, the Must requirements should be requirements that are vital for the function of the project:

  • Cannot deliver on target date without this

  • 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 the Business Case without it

These are based from reference [2].

Where To Use The MoSCoW Method

The MoSCoW Method should be used soon after you have gathered your set of requirements from the client. The method is often used in conjunction with User Stories, which can then be prioritised. An example will now be shown of how to use the MoSCoW method for prioritising User Stories:

User stories (basic) for the Starship Enterprise™ from Star Trek™ might be the following:

  • “The user can login to the application using a username and password”
  • “The user can register a new account with the application.”
  • “The user can view all new singularities in the local area network.”
  • “The user can go on vacation in the holodeck.”
  • “The user can beam from the ship to another location”
  • “The user can wear a red shirt”

Using the MoSCoW method, these can be prioritised as follows:

  • “The user MUST login to the application using a username and password”
  • “The user SHOULD register a new account with the application.”
  • “The user SHOULD view all new singularities in the local area network.”
  • “The user COULD go on vacation in the holodeck.”
  • “The user MUST beam from the ship to another location”
  • “The user WOULD wear a red shirt”

These are based from reference [3].

Presentation

You may choose to embellish your MoSCoW requirements with icons or a color scheme that makes them easier to identify. If you do this, consider how professional the final result looks and the type of client you are working with. For example:

  • 🔴 Must - red could signify the vital/blocking nature of these items.
  • 🟡 Should - yellow could signify the important, but not vital items.
  • 🟢 Could - green could indicate the items that are nice to have.
  • 🔵 Won’t/Would - blue could indicate the items that will not be considered.

Or:

  • 🥉 Must - a bronze medal could signify the vital/blocking nature of these items.
  • 🥈 Should - a silver medal could signify the important, but not vital items.
  • 🥇 Could - a gold medal could indicate the tasks that are nice to items.
  • ❌/💎 Won’t - a crossmark could be used for ‘Won’t’ have items, or a diamond for ‘Would’ have items.

References

[1] Clegg, Dai; Barker, Richard (1994). Case Method Fast-Track: A RAD Approach. Addison-Wesley. ISBN 978-0-201-62432-8.

[2] Volkerdon. MoSCoW prioritization technique. https://www.volkerdon.com/pages/moscow-prioritisation

[3] John O’Connor. Prioritizing Your User Stories with the MoSCoW Method. https://sax1johno.medium.com/prioritizing-your-user-stories-with-the-moscow-method-8bf42d427da6