ANSWER
MoSCoW is a method used to prioritize functional and non-functional software requirements. Developed by Dai Clegg, the MosCoW method was first used as part of RAD (Rapid Application Development) then gained traction as part of the more agile Dynamic Systems Development Method. MoSCoW is an acronym which stands for:
- W – Won’t Have but Would Like in the Future
While requirements are often categorized numerically on a 3, 4, or 5 point scale, the MoSCoW method provides the added benefit of providing a pneumonic that qualitatively describes HOW requirements should be classified into each level of priority.
Must Have describes requirements that have to be implemented to have a successful system. There are no workarounds if the functionality is missing. So, if even a single “Must Have” requirement is not implemented the system is a failure.
Should Have describes requirements that if missing would significantly affect the usability of the system but for which a workaround exists. It’s not necessarily pretty or ideal but if you leave a “Should Have” requirement out the user can still manage to use the system, even if their productivity is reduced.
Could Have describes requirements that if missing do not have a dramatic impact on the usability of the system. They are nice to haves. They are still desired because they result in moderate improvement in usability and improve user satisfaction.
Won’t Have but Would Like in the Future describes requirements that are known to be outside of the current scope of the project. These may be nice to have requirements but could also be very significant requirements that merely cannot or will not be included in the current release. This category is used as a parking lot to organize future requirements.
Can the MoSCoW method be used in Agile?
Absolutely, yes! The MoSCoW method works really well within agile as it helps the practitioner identify the MVP (Minimum Viable Product) by considering all the must-have requirements. Once the project team completed all the must-have requirements, they can focus on the the next level, the should-have. Of course, the team should re-prioritize using MoSCoW after each iteration or program increment as could-have and even't won't have requirements may become must-haves.
MoSCoW is one of the core practices of the Dynamic Systems Development Method (DSDM).
Does the MoSCoW method only work for requirements?
Definitely, not! Anything which needs to be prioritized can be prioritized using the MoSCoW method. Here are some examples of prioritization using MoSCoW:
- Prioritizing initiatives or projects within a larger program
- Prioritizing training courses being considered for a development team
What factors can be used to determine the category of an item using MoSCoW?
When prioritizing requirements (or anything else) it is best to identify the factors which are important to the organization and which should be used when determining the relative priority using the MoSCoW method. Each factor can be given a score and weight which, when added together, can be used to more objectively differentiate between the requirements.
Some factors to consider when determining the priority of a requirement:
- cost to develop the requirement
- expected benefits of implementing the requirement
- regulatory demands
- team's ability (skills) to implement