The MoSCoW Method
Hi all! Having very little to do with the great city of Moscow, MoSCoW is an acronym derived from the four prioritisation categories of, MUST have, SHOULD have, COULD have and WON’T have, with the addition of interstitial ‘o’s to make it pronounceable, and indeed possibly more memorable.
Devised by businessman and coach Dai Clegg, and first getting real exposure in the Agile Business Consortium’s DSDM Agile Project Framework, MoSCoW is a framework for project prioritisation and is deployed in product management, software development and business analysis to help map out when and the extent to which a project requirement should be prioritised. The method is usually used in conjunction with timeboxing, which itself is a project planning technique that divides tasking into individual time blocks, each with its own set of deliverables, deadlines and budget.
To cover each of these categories in turn:
MUST have: A MUST have requirement is critical step in the project plan and is non-negotiable, unless all stakeholders agree otherwise and shift it down the priorities scale.
Its absence might mean –
- An inability to deliver on the target date
- Often legally impossible, or practically unsafe to proceed in its absence
- The business case becomes unviable
SHOULD have: In contrast to MUST have, SHOULD have requirements are not critical to the current delivery timebox, though they are essential requirements and will fall within the future timebox if not incorporated into the current one.
- Central but not crucial
- Makes for an uncomfortable project if omitted, but still feasible with some kind of workaround
- Though the entire business case might change if a SHOULD have requirement were to be omitted.
With additional resourcing, COULD have requirements have the capacity to improve user/customer satisfaction but are not critical. They can set the business or product apart, though their absence will not render the business or product unviable.
- Desirable but less important than other requirements
- No great impact if omitted
WON’T have (at this moment):
WON’T have requirements are the least critical requirement to the business. They tend not to be incorporated into the current timebox or the one immediately proceeding and are instead left to one side to be considered for a later timebox. They confer advantage but are often recognised as impractical to incorporate within the confines of immediate business-focused activities. If it is included in the current timebox, it is likely that a delivery or budgetary target will be missed.
What is the relevance of MoSCoW for Lean?
MoSCoW dovetails into frameworks prevalent in much Lean literature such as the Ease/Benefit Matrix – and Cost/Benefit Analysis:
- Prioritising a MUST requirement delivers the most benefit, given that it is often necessary for the business to be viable.
- Prioritising a WON’T have requirement is likely to confer the biggest cost if there is a resultant failure to meet a target.
What to prioritise, the extent to which it should be prioritised and when it should be prioritised – adopt MoSCoW and spend more time on the requirements that really add value and reduce the wastage of time spent on elements that add less value and indeed as MoSCoW demonstrates, depending on the time-frame, might actually detract from operational effectiveness.