Moscow Prioritization is a project prioritization framework by which specific initiatives can have their relative importance clearly communicated among project stakeholders. In simpler terms, the Moscow technique helps manage project requirements.
Moscow’s practical function is to ensure project goals are clearly communicated to, and debated among, project stakeholders. The Moscow prioritization framework describes four key levels of project significance, each of which can encompass any number of features/initiatives:
- Must-Have: Mission-critical features that are required for a Minimal Viable Project (MVP)
- Should-Have: Important features that support core value but aren’t critical to fundamental functionality
- Could-Have: Initiatives and goals that would lend to overall value and user-experience but won’t alter basic features if left out.
- Won’t-Have: Features and initiatives that have been deemed relevant but not a priority in the current timeframe.
Must-Have
Must-have features are those nearest to core functionality. Microsoft Word’s must-haves might include saving, printing, opening existing documents, entering and changing text, and authorizing product licenses.
Must-haves are non-negotiable in terms of the importance to projects. Asking questions like “will the product work without this feature” can help identify must-have requirements. These should be clearly defined from the start and given consensus by all major project stakeholders.
Some common questions to ask regarding must-haves include:
- Is a feature required under governmental regulations?
- Can the product be delivered without this feature?
- Is this product safe without this feature?
Must-Haves is sometimes thought of as an acronymization of Minimum Usable SubseT (MUST) encompassing features that are guaranteed to be delivered. For example, the capacity of a Word processor to accept and save user input.
Should Have
Should have features include those that would benefit core user experience and value but not necessarily limit anything if excluded. For example, if Twitter didn’t support profile pictures the core features of the platform (tweeting, messaging, etc.) would still be in place. Another example might be a networked user messaging service for an online multiplayer game.
Should haves may fall into the category of matching competitor features for a more well-rounded service offering, an extension of must-have features for a more personalized experience or features more related to non-functional concerns like marketability, pricing, and subscription services.
Could Have
Could-haves are a bit like a wish list—they stand to offer value but aren’t coupled with core project value. These may include extensions to existing features, peripheral features identified in similar products or suggested by users, or improvements on existing features.
Could have initiatives are typically first-in-line to the chopping block when project deadlines run tight. A fitting name for the could-haves is if we run out of things to do’s. In other words, they’re deemed within the scope of possibility within a timebox but almost added as afterthoughts during the initial Moscow analysis.
Won’t Haves
The won’t-haves aren’t necessarily meant to be excluded indefinitely—just during the current development cycle. These are features that, for whatever reason, have been deemed as unjustifiable given the project budget or timeframe. These could include major feature additions, new versions of products, or entire refactorizations (because that gets prioritized so often.)
It’s important to understand that won’t-have features aren’t meant to be excluded forever—they may be prioritized as early as the next development cycle even. For example, Google might have decided that favicons should be displayed to a result in search engine results pages to benefit user experience. However, a broad update to their core algorithm may be given priority during their current time scope, thus forwarding the issue of favicon display until a later date.
History
Moscow Prioritization (sometimes called MoSCoW method or analysis) was developed in the mid-1990s by Dai Clegg as Rapid Application Development (RAD) approach. This new newly-formalized method was meant to help tackle so-called fast track projects (R). It found great traction in early AGILE framework iterations and was a core aspect of the Dynamic Systems Development Method (DSDM).
Moscow prioritization is a frequent framework applied to time-boxed projects, during which each boxed period receives a unique Moscow analysis. This scope-limiting approach works well with Moscow because it easily leads to the exclusion and prioritization of specific initiatives and features—knowing those left out will be available for future reconsideration.
Issues
The Moscow prioritization method isn’t without its critics. This method has been poo-pooed for lacking more granular prioritization approaches for each level. The broadness of the system also leaves important specifics, such as how to evaluate feature priority, up to the teams, and management implementing them.
