If you’re stuck trying to move a project forward because it seems like there are too many things to concentrate on then the MoSCoW method may help you get unstuck. It’s a prioritization technique which is easy to learn and simple to apply. It can also help you decide what’s really valuable for your UX projects before you get started on them.
There are many different prioritization techniques that can be employed on design projects but one of the simplest to use is the MoSCoW method. It’s used across all business disciplines to enable project teams to work with stakeholders to define requirements. It can also be used as a personal prioritization technique.
What Does MoSCoW Stand For?
MoSCoW is an (almost) acronym designed to reflect the four categories used by the technique to determine priorities; Must have, Should have, Could have and Would like but won’t get. The lower case “o’s” are added simply to give the acronym a pronounceable form. Occasionally, you may also see the whole phrase in block capitals MOSCOW to distinguish it from the name of the city but MoSCoW is more common.
What is the MoSCoW Method?
Author/Copyright holder: Busy BA. Copyright terms and licence: All rights reserved Img Src
Experts Dai Clegg and Richard Barker proposed the method in their paper “Case Method Fast-Track: A RAD Approach” and while it was initially intended to be used with the Dynamic Systems Development Method (DSDM) it has long since been adopted throughout many areas of business. In recent times it has become very popular in the Agile and RAD (rapid application development) communities.
The MoSCoW method is most effective when it comes to prioritizing requirements in projects with either fixed or tight deadlines. It works by understanding the idea that all project requirements can be considered important but that they should be prioritized to give the biggest benefits in the fastest possible time frame.
It breaks down the requirements into four categories:
Must have
These are the requirements without which a project will fail. They MUST be delivered within the timeframe in order for anyone involved with the project to move on. In essence they make up the MVP (Minimum Viable Product) though it can be argued that MUST could stand for Minimum Usable SubseT too.
Should have
Should have requirements aren’t 100% necessary for delivering the project successfully but they are the “most nice to have” out of the list. They may be less time critical than “must have” or might be better held for a future release.
Could have
Author/Copyright holder: Busy BA. Copyright terms and licence: All rights reserved Img src
Could have requirements are just “nice to have” they are desirable to provide a nice user experience or customer experience but they’re not that important to the delivery of the project. They will be delivered only if there’s enough time and resources to spare to devote to them. Otherwise, they’re likely to be tabled for future releases and re-reviewed to see if they have become higher or lower priority in the interim.
Won’t Have
These are the requirements that everyone agrees aren’t going to happen. It might be because they cost too much to implement or provide too little ROI (Return on Investment) for the efforts required to implement them. These are simply left to one side until they are either removed from the requirements list or become a higher priority.
Overall
The MoSCoW method provides a simple way of clarifying the priorities involved on a project. It’s most useful in time bound situations and it can be used to prioritize your own workload (usually with the buy in from a supervisor or manager if you work for someone else) as easily as it can be used for project work.
Implementing MoSCoW – A Practical Process
Author/Copyright holder: Railsware Blog. Copyright terms and licence: All rights reserved Img src
The easiest way to use MoSCoW is to bring together all the relevant stakeholders to the project and then:
List the requirements (on a flip chart or on a screen)
Vote on which category each requirement falls into (bearing in mind any hierarchical issues within the company itself – the CEOs vote may count for more than the votes of everyone else in the room)
Then collate the information and ensure that each requirement is presented against the relevant category in written form so that it can be used for reference by the project team
You can repeat this exercise whenever you feel it is necessary. Priorities may change mid-project or between releases. It’s important for everyone to understand what the implications of changing priorities in the middle of a project may be in terms of costs, resources, and time.
Issues with MoSCoW
It’s important to know that the MoSCoW method isn’t without its detractors. The main flaw in the method, as identified by authors Kark Weigers and Joy Beatty in their book Software Requirements, is that the method offers no means for comparing one requirement to another. This can make it difficult for those tasked with prioritizing requirements to know which category to place them in.
The Take Away
The MoSCoW method offers a simple process for prioritizing within project delivery. It can also be used to prioritize your work load. It should be used with some caution in that it may be too simple – particularly for complex projects – but it makes for a good starting point. One of the big advantages to its simplicity is that it should be easy to get buy in from other stakeholders to put it into practice.
References
Check out this useful study into how the MoSCoW method is used by business analysts.
You can read about the MoSCoW method as it was originally designed in: Clegg, Dai; Barker, Richard (2004-11-09). Case Method Fast-Track: A RAD Approach. Addison-Wesley. ISBN 978-0-201-62432-8.
You can read Weigers and Beatty’s criticism and their suggestion for a more complex method in: Wiegers, Karl; Beatty, Joy (2013). Software Requirements. Washington, USA: Microsoft Press. pp. 320–321. ISBN 978-0-7356-7966-5.
Hero Image: Author/Copyright holder: Agile Connection. Copyright terms and licence: All rights reserved. Img
