What is MoSCoW Prioritisation & How to Use it?

MoSCoW prioritisation is a prioritisation technique that product managers can use for constructing a hierarchy of priorities during the course of prioritising feature requests or backlogs. MoSCoW prioritisation framework is based on the agile project management method. Product managers use this prioritisation method to identify many factors  as early as possible, such as quality, product pricing, and requirements. 

Product managers can define clear definitions for each priority level, where specifically the MoSCoW prioritisation tackles one of the key drawbacks of less robust prioritising methods. When anything is marked as a “must-have” feature in MoSCoW prioritisation framework, everyone on the product team understands that no one can disregard it throughout the project’s development.

The product team and customer stakeholders work together to fill in the levels of the MoSCoW prioritisation model. Not only should features and concepts be assigned to each level of the MoSCoW prioritisation model, but each level should also have a set amount of resources given to it.

What is MoSCoW Prioritisation ?

When running a prioritising session, MoSCoW is an acronym to help you remember four separate categories. “MoSCoW” stands for “must-have, should-have, could-have, won’t-have” in general.

Let’s take a good look on these acronyms:

Must-Have

This category highlights the requirements or tasks that must be completed for the project to be completed successfully. There’s no avoiding them. It outlines non-negotiable requirements for achieving the desired result. Failure to finish these responsibilities on time may result in negative consequences.

Here are a few questions to consider and ask yourself as a product manager to help you figure out whether tasks or requirements fall into this category:

• Is the project still viable if you don’t finish this task?
• Is it possible to complete the entire project without this requirement?
• Is there any way you can avoid undertaking this task by devising a workaround?

If you answered no, this task would serve as the foundation for the entire project.

As a result, it falls under the “must-have” category. For example, if you’re creating an app, you’ll want to make sure it’s secure to protect users’ personal and sensitive information.

Should-Have

In terms of priority, should-have tasks come after must-haves. Once the product manager is done with both these quadrants a value is added to the project to make it more successful. However, the project will still work if the product manager leave out the should-haves. Put another way; these tasks are significant but not critical to the project’s success.

Should-have category in the prioritisation framework can be created by asking yourself if the project can still move forward if the requirements aren’t met or if there is a workaround. Product managers should, for example, incorporate social networking features within their app, but a product manager can do so without them as well.

Could-Have

Completing could-haves in the MoSCoW prioritisation framework is necessary, but they don’t bring as much value to the project as should-haves, and they also cause less harm if they’re skipped. Product managers can also refer to them as nice-to-haves to fit them into their budget and schedule.

To build this category, read over the list of chores to see what will have the most significant impact (should-haves) and what would provide the most negligible value (could-haves). If possible, a product manager may include a dark mode option in your app.

Won’t-Have

This category represents the MoSCoW prioritisation method’s lowest priority. It contains tasks that are completed within a given budget and deadline. The absence  or presence of won’t-haves has no bearing on the project’s completion and success. But there may be chances of bearing in the future of this particular project or on another project.

Won’t-have category allows the product managers to focus their attention and resources. For example, if a product manager can add a new security feature to their app through an update to patch software vulnerabilities.

How Does MoSCoW Prioritisation Work?

Do you as a product manager find it challenging to perform your tasks regularly? Organising and prioritising them may be the answer, and the MoSCoW prioritisation approach might assist you with this. 

When a product manager has an extensive list of tasks to complete, multitasking appears to be the best way to manage the time. However, juggling many tasks has the disadvantage of leaving the product manager with a pile of incomplete tasks and a sense of irritation at the end of the day.

The MoSCoW prioritisation method is typically applied early in a project’s life cycle. The team, project managers, department heads, high management, and stakeholders collaborated to create the final list. Everyone with a stake in the project is expected to participate in the process of classifying the various products into distinct categories. This ensures that the project runs well, with everyone understanding and aligned with the project’s and stakeholders’ priorities and objectives.

As a result, the MoSCoW prioritisation method enables projects to work with a broader perspective and obtain consensus on many tasks, allowing for more effective decision-making.

To get the most out of it, there are a few things to bear in mind when utilising the MoSCoW prioritisation method.

1. Balancing MoSCoW Priorities

It’s critical to know precisely what the must-have priorities are before deciding. Defining a product’s minimum usable subset is one way to determine must-haves. This is a statement of a project’s minimum criteria for it to be viable, functional, and, by all accounts, a success.

Other priorities, as a result, automatically become a contingency, with no direct impact on a project’s functionality or success beyond the must-haves.

When using MoSCoW prioritisation to manage a project, balancing all categories of prioritising becomes critical. Having more must-haves than a team can handle or afford is a recipe for disaster. A reasonable rule of thumb is that must-haves should account for no more than 50% of your tasks and team effort. This gives the team time to gain confidence in their work and their ability to meet deadlines.

2. Defining MoSCoW Prioritisation Categories

When discussing priorities with a group of individuals, must-haves are usually obvious to spot. The distinction between “Should-Have” and “Could-Have” priority, on the other hand, is subjective and can be a matter of conflict if there are sharply opposing viewpoints.

As a result, it’s always a good idea for the product managers to be very explicit about the definitions and extent of the categories in question and discuss them with each stakeholder upfront. 

3. Prioritisation Right Time

Prioritisation is vital, and this primarily refers to any new requirements that arise during the course of the project’s development. New requirements will need to be classified using the MoSCoW prioritisation method, but they cannot be too disruptive to the current process. Most importantly, they should not go beyond the previously agreed-upon limit of 50% of work being covered by must-haves since this can quickly demoralise the workforce.

Knowing the right time to prioritise any new requirements is critical to a project’s success.

4. Reviewing Priorities

All priorities must be re-examined and discussed with stakeholders at the end of each deliverable or project increment. The working process frequently reveals incorrect and missing priorities, which must be addressed in the following deliverable. It’s also good for the product manager to go over all of the priorities again because a low-priority task could suddenly become more crucial in the project. 

MoSCoW Prioritisation Rules

The MoSCoW prioritisation rules or principle states that the “musts” should be completed in 50-60% of the time allotted, and the “Must and Should” should be completed in 60-70% of the time. The product manager can satisfy his/her client or boss with 80% of his/her available time, leaving 20% for delighting them. It also means that a product manager can still complete “Must and Should” if they take longer than expected.

So, here’s what you as a product manager should do. Have a discussion about the MoSCoW prioritisation strategy with your clients, stakeholders, or boss. Make sure you’re both on the same page regarding what belongs in which category. 

At first, you’re almost probably not going to be. 

Next, figure out how much time you’ll need for “Must and Should”, and make sure you’re not going over the 60% and 80% limits. This is critical for a few reasons.

To begin with, if “Must and Should” are predicted to use more than 80% of your time, they will require more than 100% if things become sticky, in which case you will fail. 

Second, regularly delivering on “Must and Should” does not usually lead to advancement. They advance by regularly delivering on “Must and Should” while simultaneously pursuing some interesting “Could” opportunities. 

So, how are you going to make your 20% time, and what will you do with it?

When Do We Use This MoSCoW Prioritisation Method?

Prioritisation using the MoSCoW method is utilised early in the project management cycle, but it isn’t always the first step. Before the team begins organising the needs by priority, they must first define the project requirements.

Although the team will categorise all of the project’s requirements by priority during the initial phase of MoSCoW, this is not the end of the process. Reevaluate the remaining milestones after each one is completed.

‍

For example, during the initial MoSCoW prioritisation framework discussion, the product team may have requirement X that falls into the could-have group. However, when they’ve completed a few must-haves, they might reconsider requirement X, concluding that it needs to be implemented sooner rather than later or doesn’t provide any value.

During development, some flexibility is beneficial, but the product team try not to change the MoSCoW prioritisation model so much that it becomes redundant.

How to use MoSCoW Prioritisation?

It’s easy to feel overwhelmed when faced with an endless to-do list and other external pressures. Conducting a MoSCoW prioritisation strategy session can assist a product manager and the team in reducing this early stress and formulating a successful strategy! 

Meet the following requirements:

• a team with a compelling reason for creating a product vision 
• defining a shared problem space
• a product description

If possible, an agenda (1-page maximum) to inform everyone about this iteration’s success.

If a product manager lacks several of these crucial components, their prioritisation is likely to be inefficient. Pre-fill the MoSCoW grid with the earlier discussions made by the team while creating this shared understanding. For each item in the grid, use a basic visual code. Before the meeting, be sure to attach the MoSCoW prioritisation matrix or share it on the team communication platform.

Make everyone feel at ease. Explain the procedure and why the group has gathered in the room. Ask questions regarding MoSCoW prioritisation framework and make sure the definitions are clear. Make careful to include the exercise’s time frame: the next release. I’d also like to point out that nothing is ever permanent, and the product team can alter their minds at any time.

The benefit of the MoSCoW prioritisation technique comes from the incredibly stimulating conversations it will elicit. The discussions serve as a coercive tool for quickly bringing the team together. The product manager will also see the areas of misalignment or indecision. On the MoSCoW prioritisation matrix, these points will be easily visible.

Least Aligned Quadrants

It would help to begin with the quadrants that are the least absolute—specifically, the could-have and should-have options.

The suggested path will assist the team in honing their prioritisation skills.

On the left, the product team can see the intended path.

• Could-have: Try to transfer things from the could-have quadrant to the won’t-have or should-have quadrant.
• Should-have: same as above, except criteria, should be moved to the must-have / could-have quadrant.
• Must-have: It’s OK to devote some time and thought to this area.

Prepare a TO-DO list of all the necessities that will not be implemented in this release. This is usually the easiest of the two.

Strong Alignment

The Must-Have and Won’t-Have quadrants should be firmly defined if the product manager already has a good alignment. Begin with the points that have previously been agreed upon.

Must-Have: 

Begin there since this quadrant is where the team’s alignment is formed. Don’t leave any need unaddressed; instead, concentrate on the one marked with a question mark. These can either be aligned or moved to a different quadrant.

Won’t-Have: 

It should also be obvious and quick. Don’t be afraid to rearrange and clarify things.

Should-Have: 

This is where the team should spend most of the time. There will be a lot of intriguing talks to have. The majority of the discussion will revolve around the should-have vs. could-have needs.

3 Tips to run a Successful Prioritisation Meeting 

1. Feel free to prioritise based on the importance of several requirements: start with the team’s most pressing needs.

2. Another option is to go in order: Each participant selects one requirement that they believe is in the incorrect quadrant, one requirement in the correct quadrant, and one absent requirement. The final solution ensures that everyone participates fairly and is very remote-friendly.

3. Ensure that your team devotes adequate time to each quadrant

When to Apply the MoSCoW Prioritisation Method?

There are various uses for MoSCoW prioritisation method, but the common thread is that it brings together stakeholders from across an organisation. Primarily when those teams represent various departments, levels of commitment, and enthusiasm for the project under development. 

Other advantages include:

• Consensus-building
• Framing the project establishes a clear direction.
• It helps in gaining a larger perspective.
• Ensures that everyone’s expectations are met.

1. Developing New Projects

The use of MoSCoW prioritisation method aids in the breakdown of the crucial early steps. When a product needs to return on investment rapidly, this method is especially critical when there is a limited budget and a short schedule.

MoSCoW prioritisation is an excellent framing method. When done correctly, it can assist in defining the important core qualities and re-calibrate thinking. The MoSCoW prioritisation process provides advantages that go beyond simply prioritising the development of a product.

2. Keeping Expectations in Check

Prioritisation ’s overall purpose is to keep you focused on what counts - to keep the product manager on track to ensure that he/she meets particular deadlines for specific deliverables. However, it’s easy to get sidetracked along the road as people’s opinions shift and new obstacles emerge.

MoSCoW prioritisation method establishes the tone for a product schedule and serves as a source of accountability for all interested parties. Everyone at this point knows what needs to be accomplished and what may be expected during each sprint. As a result, scope creep is less likely to stymie development, and unreasonable expectations are less likely to arise.

Below is an example of prioritising product backlog using MoSCoW method.

Best Practices for Using MoSCoW Prioritisation

Project managers can use the MoSCoW prioritisation technique to prioritise work. The work that can be completed quickly in a limited timeframe. If the team lacks budget or has limited resources, for example, MoSCoW prioritisation method can be used to evaluate which tasks can be completed within those constraints.

This is especially valuable for managers who are responsible for multiple projects or cross-functional teams. This is because cross-functional teams are frequently bound by the priorities of another organisation or department. While the team is working on a new product release, there are chances that the other project manager may pressurise them to meet a deadline for a different customers’ project.

And as we all know, things come up during the course of a prioritisation life cycle.

Although effective planning helps teams remain nimble, the MoSCoW prioritisation approach may assist product teams in dealing with even the most challenging and unanticipated hurdles.

Let’s imagine the product manager outsourced the responsibility of making the goodie bag to one of its team members. That’s the small bag that each participant gets when they arrive at the location, and it usually contains a few freebies. The team member’s responsibility is to collect and physically produce the goodie bag’s precise needs.

The team members will want to know the expectations of the product manager and what they must present to you being the product manager at the end of the assignment when you delegate it. It would help if you as a product manager adequately conveyed all of the required facts to them, such as:

The requirements (MUST):

There must be 200 goody bags available. Include a copy of the event program in each bag, and both the bag and the event program must be made of recyclable materials.

The deliverables (SHOULD):

There should be three free branded products inside, such as a sheet, pencil, and stencil if at all possible.

The explanations (COULD):

If a right sponsor does the funding, the goody bag could contain something delicious, such as candy bars. As an added bonus, the bag could include a small soda can.

The specifications (WOULD):

There will be no alcohol in the bags, and the total weight will not exceed one kilogram.

MoSCoW Prioritisation Real Time Example

MoSCoW prioritisation strategy can practically be used in any industry or project type because it has more to do with project decision-making than the topic matter itself. Here is a example of MoSCoW prioritisation method to get the product manager and the business analyst started on their very first draft:

Let's look at a simple real-time scenario. How do the PM and BA classify the features that go into making a child's bike?

Must-Have

Two wheels and a frame are required.

Should-Have

• Pedals for ability to adjust the saddle
• Brakes for safe stopping
• Chain safety cover to stabilise or to fit them if needed (the last two features can be classified as "could-haves" depending on how important they are to the child/parents). 

Could-Have

Horn to warn onlookers; lovely bike colour; front suspension; and Presta valves for inflating tires are all options.

Won't-Have

Valve caps to cover the tire valves are not included, nor is a Bluetooth bike speaker.

Although it may appear weird that the pedals and brakes are not included in the "must-have" category, they are not required for a child's bike. A bike is a two-wheeled transportation device by definition; therefore, it must have two wheels and a frame to connect the wheels, but everything else is up for debate and negotiation. 

Small children, for example, can learn to ride a bike by merely using their feet, eliminating the need for pedals and brakes. This basic example also demonstrates how expectations and requirements are frequently at odds. People frequently have high expectations, but these are not the same as must-have needs, which are essential and non-negotiable.

Takeaway: 

The MoSCoW prioritisation technique can be applied to various project areas.

MoSCoW Prioritisation Advantages

‍

1. Developers can be confident that they aren't missing any essential requirements when requirements that don't satisfy the "must-have" level are placed only slightly above things that won't be produced at all. Because if something vital comes up, it can be pushed up the priority list, this higher level of trust helps to reduce project risk.

2. MoSCoW distinguishes between "must-have" and "won't-have" features because each represents a unique business case that necessitates a unique approach to analysis and solution building. With this distinction, it's easy to decide which features are essential for the product to function and which are great but not necessary.

3. Rather than building a single list of everything that needs to be included, using MoSCoW to prioritise requirements allows product managers to include or eliminate items from their backlog as they are discovered.

4. The MoSCoW technique provides a consistent vernacular for discussing needs during backlog grooming sessions or sprint planning meetings. This helps developers focus on what is genuinely important, improving estimation accuracy and allowing them to fulfil sprint goals with fewer compromises.

5. Customers will feel less frustrated with the development process as they see their feature requests executed, even if many of their suggestions were never intended to be created in the first place. They are more likely to accept what was completed because it met their requirements.

6. When a product manager uses MoSCoW to prioritise requirements, he/she can start with the highest-value items and subsequently go on to the lower-value items. This helps the product manager better grasp the problem space and provide a better solution by allowing them to learn more about themselves and the problems they need to tackle before committing to their development.

7. The prioritisation process guarantees that all stakeholders are on the same page regarding the most significant backlog items. Because developers know which items will be implemented, providing consistent estimates at each product backlog grooming session or sprint planning meeting over the development life cycle becomes easier.

8. As previously stated, the MoSCoW method is a simple and effective way to prioritise needs to match development costs. If any adjustments are needed as the story progresses, product managers can make them without worrying about how they will affect other things on the backlog.

MoSCoW Prioritisation Drawbacks

Although the MoSCoW prioritisation approach is reasonably simple, it does have certain shortcomings.

1. Because the MoSCoW prioritisation classification rules are subjective, an imbalance exists between the necessary (must have or mandatory) and the slightly desirable. When it comes to “must-have” and “should-have” lists, the blurring edges between categories make it difficult to discern which category a feature belongs in. 

2. However, “should-haves” and “could-haves” can equally be said.” This occurs as a result of the subjective nature of requirements. As a result, features or stories assigned to different categories should be addressed with considerable care and consideration, and the classification chosen should be agreed upon (or clearly explained to) all stakeholders.

3. One of the most prominent criticisms of MoSCoW is that it lacks an impartial framework for comparing initiatives. The product team will need to apply this process to their analysis. The MoSCoW prioritisation method only works if the product team along with the product manager employs a consistent scoring system for all of their projects.

4. The technique is inconsistent in its application and lacks detailed planning for each feature. Even though it may define priorities fast, the MoSCoW prioritisation  technique prioritises backlog items in four categories (similar to the Kano model, which prioritises features in separate categories). 

5. Therefore, it does not add any feature/backlog item sequencing and lacks specific planning. This makes it difficult for product managers to determine the relative importance of one feature over another within the same category. Eventually, this vulnerability in MoSCoW prioritisation approach might jeopardise the entire release.

6. To figure out which of your team's activities are must-haves for your product and just nice-to-haves, a product manager will need as much context as possible. Someone from their sales staff, for example, could be able to tell the product manager how crucial (or irrelevant) a proposed new feature is to potential purchasers. One disadvantage of the MoSCoW method is that the product manager may make poor decisions about where to slot each initiative unless the product team receives input from all relevant stakeholders.

7. Their opinions about individual efforts may sway the product team members of the product manager because MoSCoW lacks an objective evaluation procedure. One concern of utilising MoSCoW prioritisation is that a team may assume it is an objective means of measuring the things on their list. They discuss one effort, determine that it is a "must-have," and then move on to the next. On the other side, the product managers’ team will demand a clear and objective structure for ranking all activities. This is the only method to reduce the entire team's pro- or anti-item biases.