MoSCoW : Requirements Prioritization Technique

/

MOSCOW TECHNIQUE - Includes Free Template

Requirements need to be prioritized because stakeholders can’t always have everything they want, or should I say, because we can’t always give them everything they want. This is not because we don’t like their faces but because most projects are faced with a limited budget and time frame. As a BA, how do you ensure you focus on the most important requirements?

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

Using a Human Resources System as an example, here’s an explanation of the MoSCoW Technique:

MUST (M)

Defines a requirement that has to be satisfied for the final solution to be acceptable e.g. The HR system “must” store employee leave history.

SHOULD (S)

This is a high-priority requirement that should be included if possible, within the delivery time frame. Workarounds may be available for such requirements and they are not usually considered as time-critical or must-haves. e.g. The HR system “should” allow printing of leave letters.

COULD (C)

This is a desirable or nice-to-have requirement (time and resources permitting) but the solution will still be accepted if the functionality is not included e.g. The HR system “could” send out notifications on pending leave dates.

WON’T or WOULD (W)

This represents a requirement that stakeholders want to have, but have agreed will not be implemented in the current version of the system. That is, they have decided it will be postponed till the next round of developments e.g. The HR system “won’t” support remote access but may do so in the next release. 

You'll notice that the HR system features have been discussed in a decreasing order of priority - from what we must have, to what we should have, could have and won't have in that order.

Practical Application

This technique is best used when the BA has gathered all existing solution requirements.

  1. Assemble all stakeholders – Each stakeholder, with help from the BA, is responsible for assigning priorities to the requirements that fall under their purview
  2. All Requirements may be listed on a flip chart and prioritised by assigning categories to each (M, S, C or W).
  3. If there are multiple stakeholders with different opinions on what category to assign to a requirement, voting can be used to reach consensus.
  4. Present categorized requirements in a readable format - See template here
  5. The requirements should be reviewed throughout the project as stakeholder needs may evolve with time.

The BABOK Guide provides 8 criteria to be used for assigning priorities to requirements. They are:

  • Business Value: Which requirement provides the most business value? The more business value a requirement will deliver, the greater the priority stakeholders may choose to assign to it.
  • Business or Technical Risk: Some requirements pose a significant risk of project failure if not implemented successfully. The analyst may assign a high priority to this category of requirements so that if the project does fail, the least amount of effort would have been spent. 
  • Implementation Difficulty: Which requirements are the easiest to implement? Straightforward requirements may lead to quick-wins and provide an opportunity for the project team to familiarize themselves with other elements of the project before taking on more complex requirements for implementation. 
  • Likelihood of Success: Which requirements can provide quick-wins and increase the probability of project acceptance? If the objective of the project is to demonstrate value as quickly as possible and quell negative chatter, requirements that have a higher probability of success would be given high priority.
  • Regulatory Compliance: Which requirements are necessary for policy and regulation adherence? These requirements are non-negotiable and usually have to be implemented within a set period of time, causing them to take precedence over stakeholder requirements in some cases.
  • Relationship to other requirements: Which requirements support other high-value business requirements? Such requirements may be assigned a high priority because of their link to important requirements.
  • Urgency: Which requirements have a high degree of urgency? Most stakeholders tend to place a high priority on requirements needed like yesterday
  • Stakeholder Agreement: Requirements on which stakeholders disagree should be postponed or assigned a low priority until consensus can be reached on their usefulness.

The above criteria can be used for prioritizing requirements by assigning weights to each requirement using a decision table. Requirements with the highest scores receive greater priority than those with lower scores. Other useful techniques for requirements prioritization are time-boxing and voting.

MoSCoW technique was introduced by Dai Clegg of Oracle UK in 1994.