MoSCoW

The MoSCoW method is a prioritization technique to reach a common understanding with stakeholders on the importance of requirements.

After the needs have been clarified in Product Discovery and priorities have been derived, product requirements need to be provided to the team:

MoSCoW is used when finally listing all requirements on a product or feature when handing over to Product Delivery. The acronym stands for

• Must haves: Features that are absolutely critical, without such a feature the product shouldn’t even be launched or delivered

• Should haves: Features that are important but when they cannot be implemented within the given time frame, the product can still be used and, hence, should be shipped

• Could haves: Features that are nice-to-haves and would improve the user experience but absolutely will not be a blocker for a release if they cannot be delivered in time

• Won’t haves: Features that are explicitly scoped out

Even though a bit boring to read for the human reader, with MoSCoW, very precise, unambiguous requirements can be listed, such as in:

• Must be able to do A
• Must be able to do B
• Should be able to do C
• Could be able to do D
• Won’t do E
• Won’t do F

However, a downside is that these MoSCoW-based requirements are very isolated from each other and don’t really explain how a user is supposed to interact with the product or the flow of interactions. This is where User Story Maps come in handy.