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.<\/p>\n
Moscow’s practical function is to ensure project goals are clearly communicated to, and debated among, project stakeholders.\u00a0 The Moscow prioritization framework describes four key levels of project significance, each of which can encompass any number of features\/initiatives:<\/p>\n
Must-have features are those nearest to core functionality. Microsoft Word’s\u00a0must-haves<\/em> might include saving, printing, opening existing documents, entering and changing text, and authorizing product licenses.<\/p>\n 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.<\/p>\n Some common questions to ask regarding must-haves include:<\/p>\n Must-Haves is sometimes thought of as an acronymization of Minimum Usable SubseT<\/strong> (MUST) encompassing features that are guaranteed to be delivered. For example, the capacity of a Word processor to accept and save user input.<\/p>\n 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\u00a0core<\/em> features of the platform (tweeting, messaging, etc.) would still be in place. Another example might be a networked user messaging service<\/a> for an online multiplayer game.<\/p>\n 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.<\/p>\n Could-haves are a bit like a wish list\u2014they 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.<\/p>\n 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\u00a0if we run out of things to do’s.\u00a0<\/em>In other words, they’re deemed within the scope of possibility within a timebox but almost added as afterthoughts during the initial Moscow analysis.<\/p>\n The won’t-haves aren’t necessarily meant to be excluded indefinitely\u2014just 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\u00a0that<\/em> gets prioritized so often.)<\/p>\n It’s important to understand that won’t-have features aren’t meant to be excluded forever\u2014they 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.<\/p>\n\n
Should Have<\/h2>\n
Could Have<\/h2>\n
Won’t Haves<\/h2>\n
History<\/h2>\n