MoSCoW method

MoSCoW Method: How to Make the Best of Prioritization

Prioritization played a significant role in the success of most feature-rich apps like Slack and GitLab. Initially, they offered a limited set of functionalities essential for their users. With time, this set was supplemented with other features. Railsware is going to share its own style of prioritizing and show how we use the MoSCoW method to get long lists of tasks done.

MoSCoW prioritization

Why do you need prioritization?

As a rule, the daily routine includes a bunch of tasks. Ideally, you’ll have enough time and energy to cover all of them – but it just might happen that the number of tasks is immense and the resources available are not in abundance. That’s where prioritization comes in.

This term denotes a process to filter what you have to do in the order of importance or relevance. For example, if you’re building a house, you are not likely to begin with the roof or walls until your foundation is done. Of course, things are much more complicated in the web development industry, and this example cannot reveal the full-scope value of setting priorities.

Complex projects and numerous startups make use of advanced prioritization techniques. These usually consist of frameworks known for specific requirements or rules that improve decision-making. Success in prioritization is often determines the success of the company itself. Getting caught up in pending and undone tasks is a straight road to failure. That’s why businesses pay particular attention to which prioritization methods to use. There are quite a few of them, but they all have some common characteristics such as orientation towards input (internal or external), and quantitative or qualitative tools.

By the way, we are hiring. Check out our job openings.

External orientation means that you need to involve stakeholders outside the development team to set priorities, while the internally-oriented methods can be executed purely in-house. Quantitative methods entail a deeper focus on numeric metrics in prioritization, and the qualitative one rests on expert opinions, votings, classifications to a greater extent. In view of this, they are traditionally divided into the following categories:

MoSCoW framework

Here you can read about different Agile prioritization techniques in detail.

Railsware prefers a technique developed by Dai Clegg in far 1994. Initially, it was named MSCW, but two O’s were added to improve pronounceability. This also made it sound like the capital city of Russia. Let’s see how it works.

What is MoSCoW?

To understand the gist of the MoSCoW method, we need to look at its origin – dynamic systems development method (DSDM). It is a framework for Agile project management tailored by practitioners with the aim of improving quality in RAD (rapid app development) processes. A hallmark of DSDM projects is strictly determined quality, costs and time at an early stage. In view of this, all the project tasks have to be allocated by the importance. The need for managing priorities triggered the invention of specialized prioritization mechanism.

This mechanism was implemented via MoSCoW – a simple yet powerful solution to set priorities both with and without timeboxes. However, it shows better efficiency if you have a certain deadline for a task, feature, subfeature, functionality, etc. The framework is applicable to all levels of project prioritization from top to bottom, as well as to all functions and focus areas.

The MoSCoW abbreviation (except for vowel letters) is carved with first letters of the priority categories it works with. These are Must-haves, Should-haves, Could-haves and Won’t-haves. And that’s how you can define which task falls on which category.

Prioritization rules

These rules or requirements estimate the importance of any task/process/feature/etc. Each company or work team uses its own approach to setting requirements, but, in general, they do not differentiate much and look as follows.



These are top-priority requirements, which shape the foundation of the major pipeline. Avoiding them means blocking the entire project or further activities. As a rule, product inception depends entirely on defining must-haves using such pointers as ‘required for launch’, ‘required for safety’, ‘required for validation’, ‘required to deliver a viable solution’, etc.

  • Can we move forward with the project if this task is undone? – if NO, it’s MUST


This type of requirement is of secondary priority. Should-haves do not affect the launch and, traditionally, are considered important but not crucial. They differ from must-haves by the availability of a workaround. Therefore, the failure of a should-have task is unlikely to cause the failure of the entire project. If you’re building a product, it will still be usable even if these requirements aren’t met.

  • Will we move forward with the project if this task is done a bit later? – if YES, it’s SHOULD


The next requirement is less important than the two previous ones but still wanted. If we compare could-haves with should-haves, the former is defined by a lower degree of adverse effect if omitted. Traditionally, the third-level priority requirements in the Agile framework MoSCoW are realized if a project is not highly constrained in time. Within the product development, we can call them low-cost tweaks.

  • Can we sacrifice this task till deadline? – if YES, it’s COULD


You can also encounter this type of requirement under the name of would-have or wish-to-have, but these variants are not recognized by the Wiki. However, regardless of the chosen name, these requirements define the lowest priority for tasks that are unviable to implement with a particular budget and deadline. Won’t-have does not mean a complete rejection of something. It envisions reintroduction under favorable conditions in the future.

  • Can we back to it when things go better? – if YES, it’s WON’T

How to use

Everything looks simple in theory, but is it in practice? Let’s check how a MoSCoW analysis of functionality prioritizing works through the example of a regular web application. As a sample, we’re going to use basic functions taken from one of Railsware products:

  • A user can sign up
  • A user can log in
  • A user can reset password
  • A user can choose the billing system
  • A user can delete the account
  • A user can open a time-tracking page
  • A user can choose time-tracking options
  • A user can install a mobile app version
  • A user can choose the app’s visual theme

Based on particular requirements for budget and time, we can single out the most fundamental features to be implemented in the minimum viable product. After the priority analysis, we’ve got the following:

  • A user MUST sign up
  • A user MUST log in
  • A user MUST reset password
  • A user MUST open a time-tracking page

The top-priority tasks are followed by important, though not vital functionalities for the app. These are:

  • A user SHOULD choose the billing system
  • A user SHOULD delete account
  • A user SHOULD choose time-tracking options

The evolution of the app does foresee its availability on mobile devices. However, this task is only nice-to-have at this point.

  • A user COULD install a mobile app version

And now the least-priority feature. It aims at enhancing the user experience once the app is on track. Theme selectability is definitely not what we’re going to make now. However, this feature is saved for later.

  • A user WON’T choose the app’s visual theme THIS TIME.

The most difficult thing about prioritization is to be icily intelligent and focus on the essential tasks to be done. Otherwise, you can get into the EVERYTHING-IS-MUST trap, according to which any feature like the billing system option or mobile app availability turns into the must-have. And that’s why MoSCoW Agile method is cool. It allows you to define a basic feature set, which has top priority and emphasizes that you do not need to abandon anything. The healthy balance of must-haves + should-haves is 50% of the entire scope. All the tasks (or almost all) will be implemented later but in the order of their importance to your goal. The goal of this example is to build an MVP, and the categorization above shows the expected progress of the app’s functionality.

We have lots of knowledge to share with you. Join Railsware team.

MoSCoW pros and cons

The framework is quite popular among Agile projects with fixed timeboxes since it allows for managing the requirements for a specific release of a product. This prioritization method has proved its efficiency and reliability within our company as well, and we do advise it to our clients. However, it is not perfect of course, and an unbiased look can reveal some flaws associated with MoSCoW technique. Let’s take a look at its strengths and weaknesses.

MoSCoW pros and cons

MoSCoW prioritization at Railsware

Let’s take a look at how we set priorities within the company.

Product development: we rest upon a roadmap where the product features and the order of their implementation are specified. As a rule, we leverage MoSCoW to define which feature goes first, which comes second, and so on, taking into account their importance and the interdependence of features. Must-haves and Should-haves are meant for the product release. Could-haves and Won’t-haves are postponed for the future.

HR and recruitment: prioritization rests upon such requirements as the demand for particular expertise, budget availability, timebox (how urgently we need this expertise), and so on. We leverage the similar patterns of setting priorities in other focus areas including on-boarding, branding, marketing, etc.

The biggest challenge of the methodology is that all stakeholders must be familiar with enough context to estimate features correctly. Besides, stakeholders that represent different functions like sales, development, marketing have their own vision of setting priorities, which not always works towards correct prioritization. Investors usually treat all features as Must-haves from their broad-based perspective and need them done without any respect of their implementation order.

Railsware has a Holacratic organizational structure. We take advantage of collective leadership based on the RASCI model and make decisions on different things including prioritization through voting. Team members can choose from several options like really want, want and don’t want. Each option implies a particular point. The option with the biggest point total has the highest priority. For small contexts, a responsible role (team leader, project manager, etc.) can be in charge of setting priorities on his/her own.

MoSCoW alternatives you may find useful for your project

Railsware uses Agile framework MoSCoW heavily and is pleased with it. However, it does not mean that we are closed to other solutions. Besides, a good product manager must consider the key product metrics and build the prioritization according to them. So here are some other worthwhile techniques that you may benefit from.

Kano Model

With this framework, you can define how happy the users are with product features. The Kano Model rests on a questionnaire, which is used to learn users’ attitude to a particular feature (like, expect, dislike, neutral, etc.). Visually, the model can be expressed via a two-dimensional diagram where the vertical axis is responsible for the level of user satisfaction (from totally frustrated to incredibly happy) and the horizontal one shows either how much was invested in the feature (Investment), how well was it implemented (Implementation), or how much users benefit from it (Functionality).

Categorization of requirements includes four types that are prioritized in the following order: must-be, performance, attractive, and indifferent. Must-bes are some basic things that users generally expect. Performance (also known as One-Dimensional) requirements are the golden mean and allow you to increase the satisfaction level. Attractive requirements are those that improve user experience. These are nice-to-haves or could-haves according to MoSCoW. Indifferent ones are less prioritized and sometimes even entirely omitted.

Kano model

Value vs. Complexity

This prioritization technique is one of the simplest. You can encounter it under the names of Value vs. Cost or Value vs. Effort as well. The method feels intuitive and is aimed at maximizing value delivery. Estimation of features’ importance rests upon how much effort is invested to implement them and how much value they will bring. Here is how it looks visually:

Value vs. Complexity

Wrapping up

The art of setting priorities shows the efficiency of your workflow. Railsware’s choice is the MoSCoW project management framework, which has made a good showing in versatile functionalities and products. However, it might be less useful for immense projects with multiple teams involved in the pipeline. We advise you to find an effective prioritization solution that fits your unique needs, and to always avoid getting caught up in countless pending tasks.