What is MoSCoW method for prioritising requirements and features of products in business analysis
MoSCoW is a well known and widely accepted method for prioritisation of requirements in software development life cycle. Its a technique which business analyst use which discussing project requirements with business stakeholders to define which requirement can be delivered and which cannot. By using the technique. they prioritise the requirements on achievable and non achievable sets. The various criteria which may affect the MoSCoW method are budget, time lines, resource availability etc.
This technique was first developed Dai Clegg who was working as a consultant in Oracle. The case method in which he described MoSCoW was Fast-Track: A RAD Approach.
MoSCoW is mostly used when a solution is being developed in a time-box manner. For example when the business gives a deadline to develop some product. Since not all features can be developed or implemented within the deadline, MoSCoW method is used to prioritise requirements and features of the product.
MoSCoW categories are as follows:
M in MoSCoW stands for Must have:
Requirements which are labelled as Must have are most important and core features of the product which should definitely go in for the success of the product or application. These are the critical feature which are first included in the timebox period. If these critical requirement are not met within the deadline then the product or application is considered as failure. These features are considered by business as minimum acceptance level. These requirements can be upgraded or downgraded as the business priority changes.
S in MoSCoW stands for Should have:
Should have requirements are those requirements which business and project teams do not consider as critical to the success of the product or application but at the same time these are considered as important features which could enhance the success and acceptance of the product. They are second in priority after the must have requirements. If all the must have requirements are met with in the timebox, then business push for these should have requirments in to the delivery timelines. If these should have requirements are are not able to fit in the timebox, then they are deferred till the next release.
C in MoSCoW stands for could have:
Could have requirements are those requirements which are non critical requirements and most of the time are see as nice to have features. In most of the cases, they are only included if some budget or time is left over after inclusion of must have and should have features. For example, in an online store application, to show customers what other customer are buying in the same segment can be considered as could have feature because its not a core functionality of the product.
W in MoSCoW stands for Won't have OR Would have:
Won't have requirements are those requirements which business think cannot be included in he current timebox development of product. This doesn't mean that these requirements are not liked by business or stakeholder. They are good to have requirements but for them business or project know for sure that they cannot be implemented in current release and hence are deferred to next release of product. Some of the books and paper term them as would have requirements meaning that they will be developed in future releases of the product.
The small 'o' in MoSCoW are just added to make the word pronounceable and easy to remember. The small letter is used to indicate that they don't mean anything. At some places all Upper case MOSCOW is also used and accepted.