Several years after I first encountered it, I still find MoSCoW one of the easiest methods for prioritisation…
The MoSCoW approach to prioritisation originated from the DSDM methodology (Dynamic Software Development Method), which was possibly the first agile methodology (?) – even before we knew iterative development as ‘agile’.
MoSCoW is a fairly simple way to sort features (or user stories) into priority order – a way to help teams quickly understand the customer’s view of what is essential for launch and what is not.
MoSCoW stands for:
Must have (or Minimum Usable Subset)
Won’t have (but Would like in future)
‘Must Haves‘ are features that must be included before the product can be launched. It is good to have clarity on this before a project begins, as this is the minimum scope for the product to be useful.
‘Should Haves‘ are features that are not critical to launch, but are considered to be important and of a high value to the user.
‘Could Haves‘ are features that are nice to have and could potentially be included without incurring too much effort or cost. These will be the first features to be removed from scope if the project’s timescales are later at risk.
‘Won’t Haves‘ are features that have been requested but are explicitly excluded from scope for the planned duration, and may be included in a future phase of development.
It’s a good idea to make sure a project has a healthy number of Should Have and Could Have requirements. This helps to provide the project with some flexibility if things start taking longer than expected, effectively providing the project with some contingency.
If a project only has ‘Must Haves’, the scope cannot be varied. Therefore the cost and timescales should not really be fixed without including a reasonable contingency. ‘Could Haves’ can be that contingency. They are effectively stretch tasks; features that will be included if possible, but the launch date will not be moved to accommodate them if there is not enough time to complete them.