| By Rameez M Sydeekin Management Essentials|Reader DisclosureOur content is reader-supported. This means we may earn a commission if you click on some of our links.
Businesses which considers customers’ requirements and priorities when they manufacture and deliver their products fare better than the ones which don’t. Businesses which understands and prioritizes these priorities according to their importance and order of execution fare even better.
When the businesses have listed the priorities and requirements, the next step is to list them in the order it has to be executed. MoSCoW method is one such method of prioritization of requirements.
MoSCoW method, developed by Dai Clegg, is one of the broadly used prioritization technique used in product management, software development, project management, and business analysis. It is widely used to approach a common stand with stakeholders. MoSCoW analysis shows priority on the significance, stakeholders place on the carriage of each requirement. This method was first used colossally with the agile project delivery framework Dynamic Systems Development Method (DSDM).
MoSCoW is usually used with timeboxing. Timeboxing is a project planning technique where a time limit is fixed for the focus to be on the most important requirements. MoSCoW is an acronym derived from the first letter of each of four prioritization categories, MUST have, SHOULD have, COULD have, and WON’T have, with the interstitial Os, which apparently means nothing, added to make the word pronounceable. While all the requirements are equally important, they are prioritized in a special way to convey the best and most sudden business benefits early. The developers, in the beginning, will try to deliver all the Must have, Should have and Could have, but the Should and Could requirements are the first to be removed if the delivery timescale is intimidated.
MUST have
MUST have is considered as an acronym for the Minimum Usable SubseT. The Must requirements are essential to the delivery timebox and are non-negotiable. If even one of the requirements is not delivered in the given time frame, the business is considered as failed. With the mutual agreement of all the stakeholders, the requirements can also be downgraded from Must have.
The factors that differentiate the Minimum Usable Subset of requirements are as follows:
Not possible to deliver on target date without this.
If it were not delivered on the target date, then there is no point in deploying the solution on the intended date.
Legally not true or possible without it.
Unsafe and insecure without it.
Impossible to deliver the business case without it.
SHOULD have
Unlike MUST have, SHOULD have requirements are not important to be delivered in the current delivery timebox, though they are essential just like the others. Should have requirements are always kept aside from the current delivery timebox so that they can be used for a future delivery timebox. By examining the number or value of people affected, the difference between a SHOULD have and a COULD have could be understood.
The factors that differentiate the SHOULD have of requirements are as follows:
Essential but not crucial.
Unpleasant to leave out, but the solution is still feasible.
Need some kind of workaround to bypass.
Leaving out the SHOULD have requirements change the entire viewpoint of the business. Hence, these requirements are best to be not left out.
COULD have
With a little development cost, the COULD have requirements could improve the customer satisfaction or user experience, though they are wanted but not important. These requirements are usually included if and only if time and resources permit. Though they set the business product apart from the rest, their exclusion won’t reduce the viability of the product.
The factors that differentiate the SHOULD have of requirements are as follows:
Essential or desirable but less important than the rest.
Don’t create much impact if left out.
WON’T have
The least critical requirements as said by the stakeholders of the businesses are WON’T have. Hence, they are not incorporated into the next delivery timebox’s schedule but rather dropped or reconsidered for a later timebox. They are advantageous items recognized as impractical to include within the restriction of the business. What happens when a WON’T have requirement is included is that product launched by the business will miss its delivery date or the budget won’t be amicable. Usually, the WON’T list of the previous timebox begins the COULD and SHOULD item lists of the next timebox.
The MoSCoW method has shown promise for a lot of businesses. While its effectiveness has been on the top for many a business, there are quite some instances where it had its own drawbacks.
Effectiveness of MoSCoW model
The main reason for its effectiveness is the fact that everyone working in the business contributes to the priority making decisions. While it is quick and easy to complete, the major advantage is that a certain percentage of resources can be allotted to each of the four haves. It gives prioritization in a quick and instinctive way. By eliminating resources in the WON’T category allows the business to allot more resources to plan for the COULD and SHOULD categories. Once the MUST category is cleared, the remaining resources can be transferred to the rest of the categories. Precise productive analysis for projects that are still in development is possible with this method.
Having a time constraint always for any project can sometimes become a drawback. If there is no effective cooperation within the business, this method can be inaccurate. Under a qualified priority structure, the successes, as well as failures, can be analyzed properly.
It is always crucial to obtain and convey a well-defined set of requirements in a prioritized manner. MoSCoW method can be accomplished quickly and maintain the required level of prioritization diversity always.
Go On, Tell Us What You Think!
Did we miss something?  Come on! Tell us what you think of this article on MoSCoW Method in the comments section.
