MoSCoW Prioritisation

MoSCoW prioritisation solves one of the main problems of less robust prioritisation tools by laying out specific definitions for each level of priority. When something is in the “must-have” level of MoSCoW, it’s immediately clear to everyone on the team that this feature cannot be overlooked during the project’s development.

Filling in the levels of the MoSCoW model is done collaboratively by the product team and the customer stakeholders. Not only should features and ideas be placed in each level of the MoSCoW model, but an amount of allocated resources should be agreed upon for each level as well.

When Do We Use It?

MoSCoW prioritisation is used early in the project management cycle, though it isn’t usually the first step. First, we need to have project requirements laid out before we can start organising the requirements by priority.

Although there is an initial phase of MoSCoW where the team will categorizse all of the project’s requirements by priority, this doesn’t mark the end of the MoSCoW process. Each time a milestone is completed, the remaining milestones should be reevaluated.

For example, we may have requirement X that falls under the could-have category during our initial MoSCoW meeting. Once we complete a few must-haves, however, we may look at requirement X differently, deciding that we do need to implement it more urgently, or that it doesn’t add any value at all.

An element of flexibility is good during development, though we try not to change the MoSCoW model so dramatically that it becomes useless.

The Four Components

Must-have

These product features are the easiest to determine. If we were designing a car, these would be tires, engine, and wheels. If we’re creating a finance software, then we might consider the ability to integrate with a user’s bank account a must-have component.

These are the minimum requirements for each project; they are non-negotiable. If we find ourselves having a hard time determining which features to place in this category, we simply ask, “Will the project fail if this feature/milestone/component isn’t met?” If the answer is “yes”, then this is a must-have component.

Should-have

The project’s should-haves are the features that are not essential to the project’s success, but will add substantial value nonetheless. These features are more focused on fulfilling customers’ wishes and expectations, rather than meeting their basic needs.

For a car, a should-have component would be the air conditioning system. This isn’t required to make the car run, but a car without an air conditioner would be less desirable. Like must-haves, we want to try and meet all of the should-have milestones by the end of the project.

Could-have

This is the catch-all category for features that are neat, interesting, or fun, but that don’t necessarily serve any greater purpose. These are the comfort items — the bonuses — of a product. That this area is where the most shifting happens during the project, with features moving from this category into won’t-haves and should-haves.

To determine if a feature is a could-have or a should-have, we consider how it will impact the value of the product to customers. In most parts of the world, a car without air conditioning will be nearly impossible to sell as a “good” car. However, a car without a parking camera, though an immensely useful feature, is unlikely to dramatically reduce the perceived value of the car.

Won’t-have

Finally, we have the won’t-haves. This category is likely to fill up with ideas as we get further along in the project development cycle. Essentially, this is where we put the features we would like to include in the product, but for some reason can’t.

There might be several reasons why we can’t implement a certain component into the product. Instead of throwing this idea in a notebook and forgetting about it, we can place it here, where we can revisit it later. We may find that some of our could-haves and maybe even some should-haves are actually won’t-haves due to unexpected limitations.

Why MoSCoW Prioritisation Is Important

There are several reasons why the MoSCoW method is useful for creating a solid product. First, it helps us create a timeline for the project by determining what needs to be completed first. Everyone knows what the most important features are, giving the whole project a sense of clarity.

Second, the MoSCoW approach is excellent for setting project expectations, both for the team and the stakeholders. It gives investors a good idea of what they can expect from the project, as well as a clear idea of what each feature is going to cost.

Third, implementing MoSCoW into our workflow helps keep the vision for the project on track. When brainstorming with colleagues, stoking creativity, and trying to push the boundaries, it’s natural for the team to step outside of the project’s requirements and limits.

While this is good for the drawing board, it’s not so good when we’re actively developing the product. MoSCoW provides everyone with a clear checklist of what they need to accomplish. as opposed to a vague and multi-faceted vision.