English
ČeštinaMoSCoW framework
We're building a comprehensive knowledge library about product development as part of our mission. The library is for anyone looking to make better decisions — primarily decisions about how to further develop a product. Whether you're an inventor, a product manager, or a Chief Product Officer, using a structured decision-making method increases your chances of building the right things for the right audience (build the right thing for the right audience). Today we'll introduce the MoSCoW framework.
Framework name: MoSCoW.
Inventor: Dai Clegg.
Year of first use: 1994.
Link to the author's original research:
Book, Case Method Fast Track: A Rad Approach (Computer Aided System Engineering) (1994).
Key figures in the framework's development:
Kurt Bittner,
Ian Spence,
Jennifer Stapleton,
Agile Business Consortium.
Key milestones in the framework's development:
Applied in Use Case Modeling (2003),
Online book, DSDM Atern Handbook,
Adoption by the Agile Business Consortium,
Academic research, Moscow Rules: A Quantitative Exposé.
History of First Use
Dai Clegg created MoSCoW to prioritize requirements in an environment with a fixed development timeline. Projects at the time had a hard deadline, and he needed a method that would establish how important each requirement was to the final product. Most new feature development in the 1990s ran as waterfall projects. MoSCoW allowed a more flexible approach to development while still hitting the original launch date.
Basic Prioritization Principles
The core principle is to develop features according to their importance within a fixed budget measured in time. Features are categorized by their contribution to the product as a whole, then built in that order.
Each category is allocated a share of that budget as a percentage of the total. The original split was 60% Must Have, 20% Should Have, 20% Could Have, and 0% Won't Have.
Development then proceeds in this order:
Must Have features,
Should Have features,
Could Have features,
Won't Have features.
Its adoption into DSDM produced an entirely new agile method that also defines how to prioritize requirements within each category.
Category Overview
Features are developed in the exact order the categories set. The further a classified feature sits from Must Have, the less likely it is to be built at all.
Must Have Features
This group guarantees the product can launch. It is also known as the Minimum Usable SubseT (MUST for short). To identify a feature in this category, check whether it has any of the following qualities:
Without it, launching the product makes no sense,
It is legally required,
It is required for safety,
It is essential, because the solution doesn't work without it,
Asked "what happens if this isn't delivered?", the answer is "development stops". If some workaround can substitute for the feature's value, it belongs in Should Have instead.
Should Have Features
This group covers features that reduce the degree of pain users experience with the finished product. That pain is usually measured by the number of users potentially affected. To identify a feature in this category, check whether it matches any of the following:
It is important but not critical to the product,
Without it the product is awkward and painful to use, but its core value is intact,
Making it work requires managing user expectations, changing processes, or both.
Could Have Features
This group covers features users don't consider Should Have. The difference between Should Have and Could Have is how much pain the user feels with the finished product. To identify a feature in this category, check whether it matches any of the following:
Users generally ask for it less often,
It has only a small impact on revenue and profit.
This category is the most likely to go unimplemented, because it sits last in the development priority order.
Won't Have Features
This group collects every remaining requirement the product could have. Features here will not be built — at least not as part of the launch.
Prioritization Example
Our product is an e-shop selling cotton clothing.
Must Have Features
Product photos of the clothing on sale, a delivery address field, the price, and a buy button.
Should Have Features
Zoom on the product photo, adding items to favorites, or letting the marketing team promote and feature products.
Could Have Features
Two-step checkout for faster purchasing, or personalized product recommendations.
Won't Have Features
Anything that won't ship with the new product — a customer loyalty program, for example.
Visual Prioritization Example
