So…if MoSCoW isn’t just the fifth largest city in the world and the beautiful capital of Russia, what is it?

MoSCoW is a qualitative technique for prioritizing requirements and is an easy, approachable way to work with project stakeholders to determine the importance and criticality of a requirement to the implemented solution.

MoSCoW stands for:

  • M – MUST

MUST requirements should be viewed as critical to the success of the current release. Examples are items that impact the solution’s security or regulatory compliance. Without these the solution will be a failure. Project managers and development teams will implement the MUST requirements prior to any other category, so it is important that a level of organizational honesty be applied when evaluating whether a requirement falls into this classification versus SHOULD.

  • S – SHOULD

SHOULD requirements are those that are also important, but may have an alternate workaround or could be deferred to a later release. As an example, integrating a user’s software license status to their registered online account should be done to ensure alignment between the purchase and use of a product. However, in light of the costs typically associated with systems integration, other forms of account enablement and monitoring might be used in the interim.

  • C – COULD

COULD requirements are usually ones that, while they might enhance usability or further automate processes, aren’t necessary for the solution to function for its intended purpose. The most common term for these requirements is "nice to have". These requirements are usually the fun ones to define as the organization sees these as their best option for creativity and improvement over the status quo. However, it is important for everyone to level set that implementation comes at a cost, whether budgetary or schedule. Since projects rarely have the luxury of unlimited sources of either money or time, my best recommendation is to collectively identify a hand full of the COULD requirements for inclusion in the release and save the rest for implementation based on ability. 

  • W – WON’T

WON’T requirements are those that have been ruled out for the release, but may need to be captured for future consideration. Requirements may be ruled out based on return on investment, schedule constraints, technical feasibility or even other project dependencies. The biggest issue I have encountered with these types of requirements is the reluctance of stakeholders to even voice these (knowing their lower value) or agree that a currently documented requirement falls into this category. It is crucial to clearly state why a given requirement is a "W" and ensure that the impacted stakeholders understand that it is only ruled out for the current release and may still be considered at a later date should time, budget or other changes allow.

MoSCoW isn’t a foolproof way of prioritizing requirements. As a qualitative approach, it is by its nature inherently subjective. In some cases a quantitative approach is safer, especially with highly antagonistic teams. However, I have found that, at a minimum, it is approachable, especially for stakeholders that are new to the process of software requirements elicitation and analysis.