Whenever stakeholders are involved in either business decisions or software development, they will place specific requirements forward that are required or desired through the development of the program or business model. Prioritising these requirements is a vital component in the ultimate success of the project and the MoSCoW Method is a technique that is used to simplify the process.
Stakeholders can be defined as any individual, whether part of the business or client, who has a vested interest in whatever development is being planned. A stakeholder could be the owner of a company, executives, investors, or even a single client who requires a specific software program developed for a singular need.
The MoSCoW Method aims to create an easily definable process of understanding priorities and in which order they are most significant. Developed by Dai Clegg, an Oracle UK Consultant, he eventually donated the intellectual property rights to the MoSCoW Method to the Dynamic Systems Development Method Consortium (DSDM).
What the MoSCoW Method Stands For
The term MoSCoW focuses on four key elements of design or processes, four categories that will be addressed during the development stage. They are: Must, Should, Could, Won’t.
Each of these categories represents priorities of the stakeholders.
MUST: refers to any requirement that absolutely must be satisfied within the development. If this requirement is not met, then the entire project will be deemed unsuccessful and unable to solve the stated problem.
SHOULD: refers to a critical component that should be fulfilled in the final development, but if it cannot be done, whether due to time constraints or other factors, it could be satisfied by other means, if absolutely necessary. In other words, a should requirement is highly important but would not deem the project a failure if it is not completely met during development.
COULD: refers to any requirement that the stakeholder would prefer to see in the final development, but isn’t considered critical. These requirements are usually considered options that can be included if the budget, resources, or time allow.
WON’T: refers to any needs or desires that the stakeholders agree won’t be included in the current phase or release of the project, but that may be addressed at some later date. Depending on the project and individuals involved, the term ‘won’t’ can sometimes be substituted with ‘would.’
The ‘o’s’ in the term MoSCoW Method were only added for ease of communicating this analytical process.
Why is the MoSCoW Method Most Used?
This analytical method is used mostly when there is a firm and fixed time deadline in place. This allows not only the stakeholders but also the developers understand what the key priorities are within the development constraints. The developers know the primary goal of the project and can then focus on the other components or requirements as time permits.
While all requirements are deemed as important, by prioritising them in this manner, both stakeholders and developers are capable of understanding what ones will offer the greatest benefit from the outset.
The M components will always be delivered, though developers will usually attempt to deliver all M, S, and C components by the deadline.