hosa creative problem solving rubric

• Your Project
• MoSCoW Method

What is the MoSCoW Method?

The MoSCoW Method is a prioritization tool that helps professionals in managing their time and effort .

To do so, it proposes to classify the importance of the different characteristics of a product (or a Project) according to their importance .

Its name is an acronym of the 4 Prioritization Categories proposed (adding two “o”):

• M ust Have .
• S hould Have .
• C ould Have .
• W on’t Have .

Four Prioritization Categories

Must Have : Essential Requirements that the product or project must have.

• Critical Features without replacement.

Should Have : Important desired Requirements for the product or project.

• They can be substituted if necessary.

Could Have : Improvements to the product or project.

• There are different alternatives.

Won’t have : Characteristics agreed not to be adopted .

• No one will waste time implementing them.

Let’s see the first example:

MoSCoW Method example

Imagine that you have been hired to create a Website for a Law firm.

They want a professional Site where people can Register and, once inside, track their court cases .

Since you want to deliver the best possible Site on time, you decide to follow the MoSCoW method .

How does it look like?

Must Have :

• Solid programming without any bugs.
• A Solid Register System.
• A Safe and Reliable personal directory.

Should Have :

• A Fast Site.
• An outstanding Design.
• Notifications sent by e-mail.

Could Have :

• Custom menus.
• Suggestions.
• A Blog section with latest news.

Won’t Have :

• Paid content.
• A Public Members section.

As we usually say, this Method may seem obvious.

Then… Why is it important?

Why is the MoSCoW Method important?

Many of professionals end up wasting time , effort and resources on useless task s that are ultimately not essential at all.

Surely you have experienced this situation working in a Team:

• Everyone spends hours modifying a minor feature and, ultimately, the important thing is missing .

That is why this Method is so important:

• Because it concentrates your efforts and forces you to think about what is really important .

As you can imagine, this Tool can be employed in practically all kinds of situations.

But when do we especially recommend it?

When should you use the MoSCoW Method?

We highly recommend to use the MoSCoW Method:

• To put order and prioritization.
• To avoid wasting time with non-essential touch-ups.
• In order to meet the Essential Requirements.
• When the product can have very different characteristics.

Now, let’s see more examples:

MoSCoW Method examples

We have chosen different real examples where the MoSCoW Method can be of great help for the development of certain products.

Let’s begin:

A Wallet - MoSCoW Method example

Let’s imagine that you are developing a wallet .

As you know, wallets are very modular products.

They can have:

• Several or few departments for cards.
• Coin purse… or not.
• 1 or 2 bill slots.

There is not a canonical wallet (one that is the benchmark for all the others).

• That is why you decided to use the MoSCoW Method to develop it.

After some thoughts, you decide that your wallet:

• 2 bill slots.
• 8 compartments for credit cards.
• High resistance materials and sewing.
• Leather as its main material.
• A translucid Credit card compartment.
• A transverse horizontal compartment.
• A striking color on the inside of the bill slots.
• Completely black exterior color.
• One translucid compartment for small photos.
• A Coin purse.
• A Passport compartment.

Making a Cake - MoSCoW Method example

In this example, we’ll imagine that you are preparing a wedding Cake .

• You have a very rigid deadline (the wedding day, of course).

In addition, as you also know, Cakes can have lots of variations.

• We could say they are very modular .

That is why you decide to use the MoSCoW Method.

How does it look?

Well, your Cake:

• White coating.
• Two sugar figurines on top.
• 6 layers of sponge cake inside.
• Belgian chocolate between the layers.
• Decorations on the edges
• Sugar flowers.
• Chocolate balls.
• Scattered sugar pearls.
• Multicolor layers.
• An excessive amount of decoration.
• Fruit flavor.

Designing a Poster - MoSCoW Method example

You are now an artist hired to Design a poster for a Rock concert.

Obviously, this is a Design job with infinite variations possible.

• Also, you have a close deadline to finish it.

No need to mention that you will use the MoSCoW Method.

Finally, the Poster:

• The name of the Main rock band, very prominent.
• Images and colors that best suit their style.
• A typeface that best suits the musical style.
• An illustration related to Rock in the middle.
• The name of the rest of the bands that will play.
• Where and when it will take place.
• Where you can buy the tickets.
• Nearby metro and bus stations.
• The name of the city.
• The maximum capacity of the stadium
• At what time each band will play.

Summarizing

The MoSCoW Method is a prioritization tool that helps professionals in managing their time and effort.

It proposes to classify the importance of the different characteristics of a product in 4 Categories :

• M ust Have.
• S hould Have.
• C ould Have.
• W on’t Have.

Although this Method can be used in all kinds of situations, we highly recommend to use it:

• When working in a team .
• In Design tasks .
• When there is a close deadline .
• With modular products or projects .
• Economies of Scale
• Business Plan for Beginners
• Business Plan Basics
• How to write a Business Plan
• Cash Flow Calculation
• Raising Funds for a Business
• 4 C’s of Credit
• Business Plan Templates
• Customer Insight
• Customer Experience
• Customer Pain Points
• 4C Marketing Model
• RATER Model
• Augmented Product
• Product Mix
• Unique Selling Proposition
• DAGMAR Model
• Marketing Storytelling
• Content Marketing
• Psychographics
• Barnum Effect
• Market Segmentation
• Market Research & Big Data
• Marketing to Generation Z
• 4P Marketing Mix
• 7P Marketing Mix
• Sales Funnel
• Loyalty Ladder
• RACE Planning
• Push and Pull Marketing
• Marketing Strategy
• Marketing Templates
• Starting your own business
• From Startup to a Business
• Entrepreneur FAQs
• Start your Business Idea
• Entrepreneur Golden Rules
• Innovate or Imitate?
• Design Thinking
• SCAMPER Model
• AAR Process
• Work From Home
• Growth strategies for Startups
• VMOST Analysis
• 3P Framework
• SOAR Analysis
• TELOS Analysis
• 5 C’s of Entrepreneurship
• Crowdfunding
• BATNA & ZOPA Negotiation
• Entrepreneur with no Money
• Entrepreneurship Templates
• Strategy vs Tactics
• Mission and Vision
• Business Values
• Value Chain
• Scenario Planning
• Porter 6 Forces
• Bowman’s Strategy Clock
• GE-McKinsey Matrix
• Delta Model
• PEST Analysis
• PESTEL Analysis
• SWOT Analysis
• VRIO Framework
• Strategy Canvas
• Competitive Advantages
• Porter’s Four Corners
• 5 Ps of Strategy
• Porter’s Generic Strategies
• Porter’s Diamond Model
• Wardley Map
• Core Competencies
• Resource Based View
• Bridges Transition Model
• CAGE Distance Framework
• McKinsey’s 3 Horizons
• Vertical Integration
• Horizontal Integration
• Blue Ocean Strategy
• Red Ocean Strategy
• Porter 5 Forces
• Ansoff Matrix
• McKinsey 7S Framework
• CATWOE Analysis
• Strategy Pyramid
• Bain’s RAPID Framework
• Balanced Scorecard
• Resources and Capabilities
• Strategy of Apple
• Strategy of Amazon
• Strategy of Starbucks
• Strategy Templates
• Communicate Effectively
• COIN Conversation Model
• SCARF Model
• SBI Feedback Model
• CEDAR Feedback Model
• How to behave at a meeting
• Gibbs’ Reflective Cycle
• Bloom’s Taxonomy
• 5E Learning Model
• 9-Box Performance Grid
• SEEDS Bias Model
• Halo Effect
• Pygmalion Rosenthal Effect
• Dunning-Kruger Effect
• How to be an Entrepreneur
• How to be a Leader
• Mintzberg Managerial Roles
• Cog’s Ladder
• The Peter Principle
• How to Negotiate
• Teamwork Skills and Profiles
• Gantt Chart
• RACI Matrix
• Eisenhower Matrix
• FMEA Process
• Problem Solving
• Ishikawa Fishbone diagram
• 5 Whys Method
• 8 Disciplines Method
• ADDIE Model
• ORAPAPA Method
• Cynefin Framework
• Just In Time
• SMART Goals
• KISS Principle
• Birkinshaw’s 4 Dimensions
• Parkinson’s Law
• OGSM Framework
• OKR Methodology
• APQP Framework
• Theory of Constraints
• Success through Organization
• ADKAR Model
• Lewin’s Change Model
• Kotter’s 8-Step Model
• The Greiner Curve
• GAP Analysis
• Planning Templates
• Mean, Median and Mode
• Define your Data
• Pareto Principle 80/20 Rule
• Decision Matrix
• Decision Tree
• TARA Framework
• Root Cause Analysis
• Simplex Process
• Forecasting Methods
• Product Life Cycle
• How to use Google Trends
• Correlation vs Causation

© 2024 - Consuunt .

We're not around right now. But you can send us an email and we'll get back to you, asap.

Log in with your credentials

Forgot your details.

• Memberships

MoSCoW Method of Prioritization explained

MoSCoW Method: This article explains MoSCoW Method in a practical way. Next to what it is (meaning, acronym and origin), and which advantages are connected to using this model, this article also highlights the MoSCoW Method requirements, including a practical example. You will also learn how applying this method will enable you and the team to reach deadlines in time. Enjoy reading!

What is the MoSCoW Method of Prioritization?

Prioritising is often challenging. Particularly when it comes the implementation of new ideas and / or technologies. Everyone in an organisation always wants everything to be done right away and that is practically impossible. There are several tools available to make prioritisation easier. The MoSCoW Method of Prioritization is one them.

The MoSCoW Method is a prioritization technique, which can be used in a variety of situations.

Origin and advantages of the MoSCoW Method

The method was developed by  Dai Clegg, a developer working for the software company Oracle .

Originally, it was used to categorize product features, derived from user stories. It was later used in the Dynamic System Development Method (DSDM) . The method contains multiple prioritization categories, with labels for each requirement, making it easier to prioritise.

Even though the origin of this prioritize method is in software development, it is also highly applicable for agile project management, market launches, product releases, starting a new business or change processes.

With the MoSCoW Method, requirements are determined for the result of the project or product. It is about setting requirements by order of priority. The most important requirements need to be met first for a greater chance of success.

Meaning and acronym of the MoSCoW Method

Moscow is an acronym made up of the first letters. The two Os have been added to make the word ‘moscow’ readable, they don’t have any meaning themselves. The M stands for ‘Must haves’ , S for ‘Should haves’ , C for ‘Could haves’ and W for ‘Won’t haves’ or ‘Would haves’ .

Figure 1 – the MoSCoW Method acronym

The requirements when you start with the MoSCoW Method

It’s a good idea to first specify the requirements together with all team members before starting the MoSCoW Method. When determining the requirements, you should take into account what is important to all the stakeholders. Brainstorming with everyone involved will lead to good, qualitative requirements.

The requirements are prioritised to prevent them from becoming to expensive or unrealistic. The main goal is to come up with requirements that add the most value for the company. The project requirements are divided into one of the following categories:

M – Must haves

These are about the minimal requirements that are determined in advance that the end-result has to meet.

Without meeting these requirements, the project fails and the product won’t be use-able. They are a necessity for a workable product and there is no alternative. The ‘Must haves’ are essential. MUST is also explained as an acronym that stands for Minimum Use-able SubseTs.

As an extra exam assignment, University of Applied Sciences Automotive students have been asked to design a car that can at least drive (minimal requirements).

It’s okay if the car only has a chassis, without any bodywork. It’s about the construction of the individual parts and drive train to the combustion engine. In this case, the Must have is that they have a drivable car by the end of the academic year.

S – Should haves

These are additional and much desired requirements that have a high priority, but are not essential for a usable end product. The product will be usable even if these requirements aren’t met. When they are met, they will only add to the value of the product. Depending on the available time, you can always return to these requirements at a later time.

The University of Applied Sciences Automotive student might like to add a tow bar to the car (should have), but as long as the car can drive without the tow bar, their project will be successful. They can always add the tow bar at a later stage.

C – Could haves

These requirements can be considered if there’s time left. If not, it’s no problem and will not have a negative effect on the final result. The ‘Could haves’ have a lower priority than the ‘Should haves’ .

This option will only be included if there really is more than enough time to make it work. This category is also referred to as ‘nice to have’; they’re more a wish than an absolute requirement.

The University of Applied Sciences Automotive students would perhaps like to install a tachometer in the car. It’s not an important (exam) requirement, but it’d be great if they manage to do it.

W – Won’t haves (and would haves)

These are about wishes for the future that are often impossible to realise or cost a lot of time. If it’s simply not possible, it’s best not to waste any energy on it.

If it is achievable, then a lot of time (and money) will have to be invested and it’s labelled a ‘Would have’. ‘Would haves’ are often followed upon at a later stage after the initial project is finished.

The University of Applied Sciences Automotive students don’t have to make a car that will actually drive on public roads.

It’s meant for study. If they do want to take it on public roads, it will need bodywork and comply with safety standards. It also involves getting approval from the Vehicle Standards Agency in elaborate process.

How to reach deadlines using the MoSCoW Method of Prioritization?

Correctly applying and sticking to the MoSCoW Method will lead to a clear way to lead a project. Everyone involved with the project will know what needs to be done first, when it has to be finished and why it’s important. By assigning priorities to requirements, a project becomes more manageable and it’ll be easier to meet the deadline.

It’s Your Turn

What do you think? How do you apply the MoSCoW analysis in your project or organisation? Do you recognize the practical explanation or do you have more additions? What are your success factors for applying the MoSCoW Method?

Share your experience and knowledge in the comments box below.

More information

• Baxter, R. (2004). Software engineering is software engineering . In 26th International Conference on Software Engineering, W36 Workshop Software Engineering for High Performance System (HPCS) Applications (pp. 4-18).
• Stephens, R. (2015). Beginning Software Engineering . Wrox Publishing .
• Hatton, S. (2008). Choosing the right prioritisation method. In Software Engineering, 2008. ASWEC 2008 . 19th Australian Conference on (pp. 517-526). IEEE.
• Robson, W.A., Simon, Shena. (2014). Moscow in the making . Taylor & Francis Ltd.

How to cite this article: Mulder, P. (2017). MoSCoW Method of Prioritization . Retrieved [insert date] from Toolshero: https://www.toolshero.com/project-management/moscow-method/

Original publication date: 05/12/2017 | Last update: 05/27/2024

Add a link to this page on your website: <a href=”https://www.toolshero.com/project-management/moscow-method/”> Toolshero: MoSCoW Method of Prioritization</a>

Did you find this article interesting?

Your rating is more than welcome or share this article via Social media!

Average rating 3.8 / 5. Vote count: 8

No votes so far! Be the first to rate this post.

We are sorry that this post was not useful for you!

Let us improve this post!

Tell us how we can improve this post?

Patty Mulder

Patty Mulder is an Dutch expert on Management Skills, Personal Effectiveness and Business Communication. She is also a Content writer, Business Coach and Company Trainer and lives in the Netherlands (Europe). Note: all her articles are written in Dutch and we translated her articles to English!

Related ARTICLES

The Rational Unified Proces Methodology (RUP)

DevOps methodology explained

RASCI Chart explained including an example

Learning Management System (LMS)

Stage Gate Process by Robert Cooper explained

Test Driven Development (TDD)

Also interesting.

Burndown Chart: Theory and Excel Template

Issue Management in project management: the process explained

Critical Chain Project Management (CCPM) method

One response to “moscow method of prioritization explained”.

Thanks for providing a concise and easily understandable explanation. The one thing that stood out to me however, is the example for the Should Have section. Tow bars are clearly “Could have” at best and in this situation would probably end up in the “Won’t have” bucket simply because there’s no justification for them at all on an experimental vehicle that will not be driven on a public road. To make this more believable I’d recommend changing the example for “Should Haves” to either: Seats – the vehicle should have a seat for the driver but as long as someone can drive it somehow it’s not critical. Or Steering Wheel – ideally the vehicle should have a steering wheel, but as long as it CAN be steered (perhaps by levers) then the project will pass. Otherwise, this is a really useful article. Thanks again.

Leave a Reply Cancel reply

You must be logged in to post a comment.

BOOST YOUR SKILLS

Toolshero supports people worldwide ( 10+ million visitors from 100+ countries ) to empower themselves through an easily accessible and high-quality learning platform for personal and professional development.

By making access to scientific knowledge simple and affordable, self-development becomes attainable for everyone, including you! Join our learning platform and boost your skills with Toolshero.

POPULAR TOPICS

• Change Management
• Marketing Theories
• Problem Solving Theories
• Psychology Theories

ABOUT TOOLSHERO

• Free Toolshero e-book
• Memberships & Pricing

5 Prioritization Methods in UX Roadmapping

November 14, 2021 2021-11-14

• Email article
• Share on LinkedIn
• Share on Twitter

Prioritizing work into a roadmap can be daunting for UX practitioners. Prioritization methods base these important decisions on objective, relevant criteria instead of subjective opinions.

This article outlines 5 methods for prioritizing work into a UX roadmap :

• Impact–effort matrix 
• Feasibility, desirability, and viability scorecard
• RICE method
• MoSCoW analysis 

These prioritization methods can be used to prioritize a variety of “items,” ranging from research questions, user segments, and features to ideas, and tasks. This article focuses on using these methods within the context of roadmapping—prioritizing problems that need to be solved into a strategic timeline. 

In This Article:

1. impact–effort matrix, 2. feasibility, desirability, and viability scorecard , 3. rice method, 4. moscow analysis, 5. kano model, 1.a. overview.

An impact–effort matrix is a 2D-visual that plots relative user value against implementation complexity. Variations of this matrix are used across various product-development approaches, including Six Sigma, design thinking, and Agile.

The resulting matrix captures the relative effort necessary to implement candidate features and their impact on the users. It can be subdivided into four quadrants: 

• Quick wins include low-effort, high-impact items that are worth pursuing. 
• Big bets include high-effort, high-value items; they should be carefully planned and prototyped, and, if executed, are likely to be differentiators against competitors. 
• Money pit includes low-impact, high-effort items that are not worth the business investment; there are better places to spend time and resources. 
• Fill-ins comprise low-effort, low-impact items that may be easy to implement but may not be worth the effort as their value is minimal. 

A comparative matrix is a malleable tool. While we discuss impact–effort matrices in this article, you can easily replace each axis with other criteria or use multiple matrices to assess more than two criteria. When setting up multiple matrices, set up your axes so that the Quick Wins (or whatever the equivalent best-outcome quadrant is) is positioned in the same spot (for example, always in the bottom left position), in order to easily compare several matrices and identify the items that consistently fall in best-outcome quadrant. 

1.B. Criteria

This prioritization method uses two primary criteria to rank features that are considered for implementation: the impact that the feature will have on the end user and the effort required to implement that feature. 

• Impact is the value the item will bring to the end user. The level of impact an item will have on end users depends on the users’ need, their alternatives, and the severity of the pain point the item solves.
• Effort is the amount of labor and resources required to solve the problem. The more technically complex the item, the higher effort it will require.

1.C. Process

Items are gathered on a whiteboard and their relative scores on the impact and effort dimensions are established through voting. Team members are given colored dots (one color per dimension) to vote for those items that they consider to rate highly on one or both dimensions.  

A general rule of thumb is that the number of votes per person is half the number of items being prioritized. It’s also possible that certain team members vote on a single dimension, according to their expertise — for example, UX professionals may rank impact, while developers may rank implementation effort.

After team members have silently voted on items, the items can be placed collaboratively on an effort–impact matrix (the x-axis represents effort, while the y-axis represents impact) according to the number of impact and effort votes received. 

Once everything is placed onto the chart, discuss the results and compare items, prioritizing those in the quick-wins and big-bets quadrants. Feel free to use the artifact as a platform for negotiation — throughout discussion with the team, it’s okay to collaboratively move items. However, at the end, there should be agreement on the final placement and the artifact should be documented and saved so it can easily be referenced in the future. 

1.D. Best for Quick, Collaborative Prioritization

An impact–effort matrix is best suited for quick, collaborative prioritizations. The method has a few advantages:

• The output is a shared visual that aligns mental models and builds common ground . 
• It is democratic — each person can express their own opinion through a vote.
• It can be done relatively quickly due to its simplicity. 

2.A. Overview

This method was developed by IDEO in the early 2000s. It ranks items based on a sum of individual scores across three criteria: feasibility, desirability, and viability. 

2.B. Criteria  

This prioritization method uses three criteria to rank items (i.e., features to be implemented):

• Feasibility : the degree to which the item can be technically built. Does the skillset and expertise exist to create this solution?
• Desirability : how much users want the item. What unique value proposition does it provide? Is the solution fundamentally needed, or are users otherwise able to accomplish their goals? 
• Viability : if the item is functionally attainable for the business.  Does pursuing the item benefit the business? What are the costs to the business and is the solution sustainable over time? 

2.C. Process

Create a table, with one row for each possible item, and columns for the 3 criteria — feasibility, desirability, and viability. Then, determine a numeric scoring scale for each criterion. In the example above, we used a numeric scale from 1 to 10, with 1 being a low score. 

Next, give each item a score across each criterion. Scoring should be as informed as possible — aim to include team members who have complementary expertise. Once each item is scored across each criterion, calculate its total score and force a rank. Sort the table from highest to lowest total score, then discuss the results with your team. 

2.D. Best for Customized Criteria 

This scorecard format is highly customizable. You can add columns to reflect criteria specific to your organization’s context and goals. You can also replace the criteria with others relevant to you. For example, the NUF Test , created by Dave Gray, uses the same scorecard format, but with New , Useful , Feasible as the criteria set. 

Another common modification is assigning weights to the different criteria — with those that are very important weighing more heavily in the final score. 

3.A. Overview

RICE is a prioritization framework developed by Intercom . It takes into account four factors: reach, impact, confidence, and effort to prioritize which features to implement.

3.B. Criteria  

This RICE method is based on scoring each item on 4 different dimensions:

• Reach : the number of users the item affects within a given time period 
• Impact : the value added to users 
• Confidence : how confident you are in your estimates of the other criteria (for example, highly confident if multiple data sources support your evaluation) 
• Effort : the amount of work necessary to implement the item 

3.C. Process

Using the RICE method is straightforward. Separate scores are assigned for each criterion, then an overall score is calculated. 

• A reach score is often estimated by looking at the number of users per time period (e.g., week, year);  ideally, this number is pulled from digital analytics or frequency metrics . 
• The impact score should reflect how much the item will increase delight or alleviate friction; it is hard to precisely calculate, and, thus, it’s usually assigned a score (for example, through voting, like in the previous methods) often on a scale from .25 (low) to 3 (high).  
• The confidence score is a percentage that represents how much you and your team trust the reach and impact scores.  100% represents high confidence, while 25% represents wild guesses. 
• The effort score is calculated as “person-months” — the amount of time it will take all team members to complete the item. For example, an item is 6 person-months if it would require 3 months of work from a designer and 1 month from 3 separate developers.  

Once you have each of the 4 criterion scores, use the formula to calculate the final score for each item: multiply the reach, impact, and confidence scores and divide the result by the effort score. Then compare, discuss, and reevaluate all the items’ scores with your team.  

3.D. Best for Technical-Oriented Teams

The RICE method works well for organizations that are more technical in nature (for example, when stakeholders are comfortable with equations or spreadsheets). The RICE method also works well when there are many items that need to be prioritized. Consider including peers with diverse domains of expertise in the RICE process and assign them the task of calculating the score for the criterion that relates to their expertise. 

4.A. Overview

MoSCoW analysis is a method for clustering items into four primary groups: Must Have , Should Have , Could Have , and Will Not Have . It was created by Dai Clegg and is used in many Agile frameworks. 

4.B. Criteria

This prioritization approach groups items into four buckets: 

• Must have : items that are vital to the product or project. Think of these as required for anything else to happen. If these items aren’t delivered, there is no point in delivering the solution at all. Without them the product won’t work, a law will be broken, or the project becomes useless. 
• Should have: items that are important to the project or context, but not absolutely mandatory. These items support core functionality (that will be painful to leave out), but the project or product will still work without them. 
• Could haves : items that are not essential, but wanted and nice to have. They have a small impact if left out. 
• Will not have: items that are not needed. They don’t present enough value and can be deprioritized or dropped. 

4.C. Process

MoSCoW analysis can be applied to an entire project (start to finish) or to a project increment (a sprint or specific time horizon). 

Begin by identifying the scope you are prioritizing items for. If your goal is to create a UX roadmap, you’ll usually have to prioritize for the first three time horizons: now (work occurring in the next 2 months), next (work occurring in the next 6 months), and future (work occurring in the next year). 

Compile the items being prioritized and give each team member 3 weighted voting dots, (one dot with a 1 on it, the next with a 2 on it, and so forth). Ask team members to assign their dots to the items they believe most important, with 3 being weighed most heavily.

Add up each item’s score based on the ranked votes (3 = 3 points and so forth). Identify the items with the highest scores and make sure that everybody in the group agrees on their importance. 

As each item is discussed and agreed upon as a Must Have , move it to a new dedicated space. Repeat this process for lower-priority items and assign them to the Should Have, Could Have , and Will Not Have groups based on their scores.

Once you have assigned each item to one of the four groups, establish the resources and bandwidth required for each group, starting with the Must Haves . Keep track of the total bandwidth and resources at your disposal, distributing and allocating your total amount across Must Haves (which should get the most resources), Should Haves (with the second most resources), and finally Could Haves (with few resources).  

There is not a clear threshold for how many items should be in each group. To determine this number, return to the goal of the prioritization activity. For example, if you are prioritizing items in a backlog, there is only time for so many tasks to be achieved in one sprint. In this scenario, all Must Haves should be easily achieved within one sprint; this constraint will limit how many items cannot be placed within this group.  

4.D. Best for Teams with Clear Time Boxes

MoSCoW is a good prioritization method for teams looking for a simplified approach (given the relatively vague prioritization criteria set) and with a clear time box identified for the work. Without a clearly scoped timeline for completing the work,  teams run the risk of overloading the Must Haves (of course, everything will feel like a Must Have if the timeline is the next two years!). 

5.A. Overview

The Kano model was published by Dr. Noriaki Kano in 1984 and is a primary prioritization method in the Six Sigma framework. Items are grouped into four categories according to user satisfaction and functionality and plotted on a 2D graph. 

5.B. Criteria 

This prioritization method uses two primary criterions to rank items: functionality and satisfaction. 

• None (-2) : the solution cannot be implemented
• Some (-1) : the solution can be partly implemented
• Basic (0) : the solution’s primary functions can be implemented, but nothing more 
• Good (1) : the solution can be implemented to an acceptable degree
• Best (2) : the solution can be implemented to its full potential 
• Frustrated (-2) : the solution causes additional hardship for the user
• Dissatisfied (-1) : the solution does not meet users’ expectations
• Neutral (0)  
• Satisfied (1) : the solution meets users’ expectations
• Delighted (2) : the solution exceeds users’ expectations

5.C. Process

Each item is first assigned a satisfaction score and a functionality score. The satisfaction score should be based on user data — for example, on existing user research or on a top-task user survey asking users to rate the importance of each feature; the functionality score can be rooted in the collective expertise of the team.  

These scores are then used to plot items onto a 2D-graph, with the x-axis corresponding to functionality and the y-axis to satisfaction. Each axis goes from -2 to 2. 

Based on their placement on their scores, items fall into one of four categories: 

• The Attractive category (often called Excitement ) are items that are likely to bring a considerable increase in user delight. A characteristic of this category is the disproportionate increase in satisfaction to functionality. Your users may not even notice their absence (because they weren’t expectations in the first place), but with good-enough implementation, user excitement can grow exponentially. The items in the Attractive are those with a satisfaction score of 0 or better. These items appear above the blue Attractive line in the Kano illustration above.
• The Performance category contains items that are utilitarian. Unlike other categories, this group grows proportionately. The more you invest in items within this category, the more customer satisfaction they are likely to prompt. The items in the Performance category have equal satisfaction and performance scores and fall on the green line in the Kano illustration above.  
• The Indifferent category contains items that users feel neutral towards — satisfaction does not significantly increase or decrease with their functionality and is always 0. Regardless of the amount of investment put into these items, users won’t care. These items are all placed on the dark blue Indifference line (which overlaps with the x-axis). 
• The Must-be category are basic items that are expected by users. Users assume these capabilities exist. They are unlikely to make customers more satisfied, but without them, customers will be disproportionately dissatisfied. Items fall into the Must-be category when their satisfaction score is 0 or worse. These are the items in the purple area of the Kano diagram, below the purple Must Be line.

Once items are assigned to groups, make sure that everybody in the team agrees with the assignment. Items with scores of (0,0), (-2,0) and (+2,0) may initially belong to two groups. In these cases, discuss the item and ask yourself if user value will grow proportionately with your team’s investment. If the answer is yes, group the item with Performance . In cases this is false, group the item with Indifferent . 

Move items as needed, then prioritize items into your roadmap. Items in the Performance category should have the highest priority, followed by Must be , Attractive , then Indifferent . 

5.D. Best for Forcing a User-Centric Prioritization 

The Kano model is a good approach for teams who have a hard time prioritizing based on the user — often due to politics or a traditional development-driven culture. The Kano model introduces user research directly into the prioritization process and mandates discussion around user expectations.  

There are many more prioritization methods, aside from the five mentioned in this article. (It’s also easy to imagine variations on these 5.) One method is not better than another. Consider your project’s context, team culture, and success criteria when choosing a prioritization approach. 

Once you find an approach that works, don’t be afraid to iterate — adjust and adapt it to fit to your needs or appeal to your team. Involve others in this process. The best prioritization methods are ones that everyone on your team, including stakeholders, buy into. 

McBride, S. (2018). RICE: Simple prioritization for product managers. Intercom.  https://www.intercom.com/blog/rice-simple-prioritization-for-product-managers/

What is the Kano Model? ProductPlan.  https://www.productplan.com/glossary/kano-model/

Related Courses

Facilitating ux workshops.

Lead goal-based group activities to make decisions and establish alignment

Discovery: Building the Right Thing

Conduct successful discovery phases to ensure you build the best solution

UX Roadmaps

Set a strategic, practical plan to align, prioritize, and communicate UX work.

Related Topics

• Design Process Design Process

Learn More:

Please accept marketing cookies to view the embedded video. https://www.youtube.com/watch?v=gklsUyD6RPE

UX Design Prioritization Methods

Using a CSD Matrix in Discovery

Anna Kaley · 3 min

The Goldilocks Principle for Prototyping

Megan Brown · 3 min

Problem Space and Solution Space Research

Maria Rosala · 2 min

Related Articles:

Derailed Design Critiques: Tactics for Getting Back on Track

Rachel Krause · 6 min

Facilitating UX Workshops: Study Guide

Kate Kaplan · 5 min

How to Get Stakeholders to Sketch: A Magic Formula

Kate Kaplan · 8 min

Journey Mapping for Remote Teams: A Digital Template

Sarah Gibbons · 4 min

A Guide to Service-Blueprinting Workshops

Alita Joyce · 8 min

The Diverge-and-Converge Technique for UX Workshops

Therese Fessenden · 6 min

• Integrations
• Learning Center

MoSCoW Prioritization

What is moscow prioritization.

MoSCoW prioritization, also known as the MoSCoW method or MoSCoW analysis, is a popular prioritization technique for managing requirements. 

  The acronym MoSCoW represents four categories of initiatives: must-have, should-have, could-have, and won’t-have, or will not have right now. Some companies also use the “W” in MoSCoW to mean “wish.”

What is the History of the MoSCoW Method?

Software development expert Dai Clegg created the MoSCoW method while working at Oracle. He designed the framework to help his team prioritize tasks during development work on product releases.

You can find a detailed account of using MoSCoW prioritization in the Dynamic System Development Method (DSDM) handbook . But because MoSCoW can prioritize tasks within any time-boxed project, teams have adapted the method for a broad range of uses.

How Does MoSCoW Prioritization Work?

Before running a MoSCoW analysis, a few things need to happen. First, key stakeholders and the product team need to get aligned on objectives and prioritization factors. Then, all participants must agree on which initiatives to prioritize.

At this point, your team should also discuss how they will settle any disagreements in prioritization. If you can establish how to resolve disputes before they come up, you can help prevent those disagreements from holding up progress.

Finally, you’ll also want to reach a consensus on what percentage of resources you’d like to allocate to each category.

With the groundwork complete, you may begin determining which category is most appropriate for each initiative. But, first, let’s further break down each category in the MoSCoW method.

Start prioritizing your roadmap

Moscow prioritization categories.

1. Must-have initiatives

As the name suggests, this category consists of initiatives that are “musts” for your team. They represent non-negotiable needs for the project, product, or release in question. For example, if you’re releasing a healthcare application, a must-have initiative may be security functionalities that help maintain compliance.

The “must-have” category requires the team to complete a mandatory task. If you’re unsure about whether something belongs in this category, ask yourself the following.

If the product won’t work without an initiative, or the release becomes useless without it, the initiative is most likely a “must-have.”

2. Should-have initiatives

Should-have initiatives are just a step below must-haves. They are essential to the product, project, or release, but they are not vital. If left out, the product or project still functions. However, the initiatives may add significant value.

“Should-have” initiatives are different from “must-have” initiatives in that they can get scheduled for a future release without impacting the current one. For example, performance improvements, minor bug fixes, or new functionality may be “should-have” initiatives. Without them, the product still works.

3. Could-have initiatives

Another way of describing “could-have” initiatives is nice-to-haves. “Could-have” initiatives are not necessary to the core function of the product. However, compared with “should-have” initiatives, they have a much smaller impact on the outcome if left out.

So, initiatives placed in the “could-have” category are often the first to be deprioritized if a project in the “should-have” or “must-have” category ends up larger than expected.

4. Will not have (this time)

One benefit of the MoSCoW method is that it places several initiatives in the “will-not-have” category. The category can manage expectations about what the team will not include in a specific release (or another timeframe you’re prioritizing).

Placing initiatives in the “will-not-have” category is one way to help prevent scope creep . If initiatives are in this category, the team knows they are not a priority for this specific time frame. 

Some initiatives in the “will-not-have” group will be prioritized in the future, while others are not likely to happen. Some teams decide to differentiate between those by creating a subcategory within this group.

How Can Development Teams Use MoSCoW?

  Although Dai Clegg developed the approach to help prioritize tasks around his team’s limited time, the MoSCoW method also works when a development team faces limitations other than time. For example: 

Prioritize based on budgetary constraints.

What if a development team’s limiting factor is not a deadline but a tight budget imposed by the company? Working with the product managers, the team can use MoSCoW first to decide on the initiatives that represent must-haves and the should-haves. Then, using the development department’s budget as the guide, the team can figure out which items they can complete. 

Prioritize based on the team’s skillsets.

A cross-functional product team might also find itself constrained by the experience and expertise of its developers. If the product roadmap calls for functionality the team does not have the skills to build, this limiting factor will play into scoring those items in their MoSCoW analysis.

Prioritize based on competing needs at the company.

Cross-functional teams can also find themselves constrained by other company priorities. The team wants to make progress on a new product release, but the executive staff has created tight deadlines for further releases in the same timeframe. In this case, the team can use MoSCoW to determine which aspects of their desired release represent must-haves and temporarily backlog everything else.

What Are the Drawbacks of MoSCoW Prioritization?

  Although many product and development teams have prioritized MoSCoW, the approach has potential pitfalls. Here are a few examples.

1. An inconsistent scoring process can lead to tasks placed in the wrong categories.

  One common criticism against MoSCoW is that it does not include an objective methodology for ranking initiatives against each other. Your team will need to bring this methodology to your analysis. The MoSCoW approach works only to ensure that your team applies a consistent scoring system for all initiatives.

Pro tip: One proven method is weighted scoring, where your team measures each initiative on your backlog against a standard set of cost and benefit criteria. You can use the weighted scoring approach in ProductPlan’s roadmap app .

2. Not including all relevant stakeholders can lead to items placed in the wrong categories.

To know which of your team’s initiatives represent must-haves for your product and which are merely should-haves, you will need as much context as possible.

For example, you might need someone from your sales team to let you know how important (or unimportant) prospective buyers view a proposed new feature.

One pitfall of the MoSCoW method is that you could make poor decisions about where to slot each initiative unless your team receives input from all relevant stakeholders. 

3. Team bias for (or against) initiatives can undermine MoSCoW’s effectiveness.

Because MoSCoW does not include an objective scoring method, your team members can fall victim to their own opinions about certain initiatives. 

One risk of using MoSCoW prioritization is that a team can mistakenly think MoSCoW itself represents an objective way of measuring the items on their list. They discuss an initiative, agree that it is a “should have,” and move on to the next.

But your team will also need an objective and consistent framework for ranking all initiatives. That is the only way to minimize your team’s biases in favor of items or against them.

When Do You Use the MoSCoW Method for Prioritization?

MoSCoW prioritization is effective for teams that want to include representatives from the whole organization in their process. You can capture a broader perspective by involving participants from various functional departments.

Another reason you may want to use MoSCoW prioritization is it allows your team to determine how much effort goes into each category. Therefore, you can ensure you’re delivering a good variety of initiatives in each release.

What Are Best Practices for Using MoSCoW Prioritization?

If you’re considering giving MoSCoW prioritization a try, here are a few steps to keep in mind. Incorporating these into your process will help your team gain more value from the MoSCoW method.

1. Choose an objective ranking or scoring system.

Remember, MoSCoW helps your team group items into the appropriate buckets—from must-have items down to your longer-term wish list. But MoSCoW itself doesn’t help you determine which item belongs in which category.

You will need a separate ranking methodology. You can choose from many, such as:

• Weighted scoring
• Value vs. complexity
• Buy-a-feature
• Opportunity scoring

For help finding the best scoring methodology for your team, check out ProductPlan’s article: 7 strategies to choose the best features for your product .

2. Seek input from all key stakeholders.

To make sure you’re placing each initiative into the right bucket—must-have, should-have, could-have, or won’t-have—your team needs context. 

At the beginning of your MoSCoW method, your team should consider which stakeholders can provide valuable context and insights. Sales? Customer success? The executive staff? Product managers in another area of your business? Include them in your initiative scoring process if you think they can help you see opportunities or threats your team might miss. 

3. Share your MoSCoW process across your organization.

MoSCoW gives your team a tangible way to show your organization prioritizing initiatives for your products or projects. 

The method can help you build company-wide consensus for your work, or at least help you show stakeholders why you made the decisions you did.

Communicating your team’s prioritization strategy also helps you set expectations across the business. When they see your methodology for choosing one initiative over another, stakeholders in other departments will understand that your team has thought through and weighed all decisions you’ve made. 

If any stakeholders have an issue with one of your decisions, they will understand that they can’t simply complain—they’ll need to present you with evidence to alter your course of action.  

Related Terms

2×2 prioritization matrix / Eisenhower matrix / DACI decision-making framework / ICE scoring model / RICE scoring model

Prioritizing your roadmap using our guide

Talk to an expert.

Schedule a few minutes with us to share more about your product roadmapping goals and we'll tailor a demo to show you how easy it is to build strategic roadmaps, align behind customer needs, prioritize, and measure success.

Share on Mastodon