Kano Model vs MoSCoW – How Do You Prioritise?

They say time is infinite. Theoretical Physicists may agree, but anyone involved with Projects knows only too well that time is finite. No matter what you are delivering in your portfolio or project, there never seems to be quite enough time to get everything the customer wants delivering. More often than not, we end up negotiating on scope – agreeing which scope items are mandatory, and which can be skipped without affecting the business case.

The problem is one that Agile project managers are very familiar with. When delivering within fixed iterations to high standards of quality, the only thing you can flex is the scope. One of the most popular methods of prioritising scope (or stories) is a technique called MoSCoW that was developed by Dai Clegg and later adopted by DSDM.

Introduction

Prioritisation frameworks are essential tools for product managers to make informed decisions about which features to prioritise and when. By using a prioritisation framework, product managers can ensure that their team is working on the most important tasks first, aligning with the company’s business objectives and customer needs. In this article, we will explore the different types of prioritisation frameworks, their benefits, and challenges, and provide guidance on how to choose the right framework for your team.

Definition and Importance of Prioritisation Frameworks

A prioritisation framework is a structured approach or methodology used to evaluate, rank, and prioritise tasks, features, projects, or initiatives. It provides a set of consistent principles and strategies that help teams decide what to work on next. Prioritisation frameworks are essential for product managers to make sure they’re working on the most important things first, enhancing customer value, and minimising the risk of working on something that nobody wants.

Benefits of Using a Prioritisation Framework

Using a prioritisation framework has several benefits, including:

Enhanced customer value: Frameworks keep the team focused on tasks that satisfy customer needs.
Prioritisation frameworks help teams make objective, data-driven decisions and allocate resources efficiently.
They provide a clear understanding of value, goals, and customer needs, which is essential for effective prioritisation.

Challenges of Prioritisation

Prioritisation can be challenging, especially when dealing with multiple stakeholders, limited resources, and changing market conditions. Some common challenges include:

Managing stakeholder expectations
Adapting to changing market conditions
Dealing with limited information
Limited resources
Bias can influence prioritisation decisions
Lack of alignment can lead to prioritisation becoming a fight between different teams

MoSCoW prioritisation framework

The MoSCoW method asserts that all requirements are desired, but they should be ordered to deliver the most significant and most immediate business benefits early. The MoSCoW method helps in aligning product features with business value, ensuring that resources are allocated to those that deliver the most significant impact and relevance in the product development lifecycle. Requirements are sorted into one of four categories: Must have, Should have, Could have, and Won’t have. Teams will set out to deliver the Must, Should, and Could requirements, but the Could and Should requirements are first to be descoped if the timeline is at risk.

The Categories are defined as follows:

Must-Have

Requirements labelled as Must-Have are critical to the current delivery timebox for it to be a success. If even one Must-Have requirement is not included, the project delivery should be considered a failure (note: requirements can be downgraded from Must.

Should-Have

Requirements labelled as Should-Have are important but not necessary for delivery in the current delivery timebox. While Should-Have requirements can be as important as Must-Haves, they are often not as time-critical. For example, there may be another way to satisfy the needs of the customer, so that work be held back until a future delivery timebox or a later project.

Could-Have

Requirements labelled as Could-Have are desirable but not necessary and could improve the user experience or customer satisfaction for a little development cost. These will typically be included if time or budget permits.

Won’t-Have

Requirements labelled as Won’t-Have are agreed by stakeholders as the least-critical items. This is not to say that they are not valuable – just that they are not needed at this time and can either be dropped or pushed to a later delivery window.

When to Use the MoSCoW Method

The MoSCoW method is suitable for small projects and products that don’t have many technical limitations and dependencies. It’s also a good fit for teams that need a simple and easy-to-understand prioritisation framework. However, it may not be the best approach for complex products where teams may not be aware of the impact their decisions may have on other teams downstream of them.

The problem with MoSCoW dynamic systems development method

The problem with this prioritisation approach lies not with the method itself, but with its application. Imagine a scenario where your team has a backlog of requirements that the sales and marketing team would like a product team to invest in. These types of requests are typically backed by a sense of urgency and promises of high-value sales/conversions. Based on our MoSCoW ranking system, we would categorise these based on their ability to deliver tremendous and immediate business benefits and would, therefore, classify them as ‘Must-Have.’ Other items are descoped, or recategorised to compensate. The danger with this approach is that it is typically the exciting and new requirements that end up making the cut, while anything that can be put off ends up being deferred indefinitely. A well-structured prioritisation process can help mitigate these issues by ensuring a balanced approach to both new features and essential maintenance tasks. A typical pattern is for work such as refactoring, maintenance, and efficiency improvements shelved in favour of new features.

How can Kano help customer satisfaction?

In 1984, Noriaki Kano and three colleagues, Nobuhiko Seraku, Fumio Takahashi and Shin’ichi Tsuji, developed the Kano Model of Customer Satisfaction. Using the model, we can divide requirements into three categories: Baseline Expectations, Linear Satisfiers, and Delighters. Customer feedback is crucial in identifying these categories, as it provides insights into what customers expect, appreciate, and find delightful.

Baseline Expectation: Requirements are those that must be present for the product to be successful.
Linear Satisfiers: Requirements are those that are on a sliding scale. The more we have, or the better they are – the more customer satisfaction they bring. Conversely, the worse they are, the more dissatisfaction they bring. A good example here may be the speed of a website or the number of free Excel templates available for download on a website for PMO professionals!
Delighters: are requirements that will delight your customer and ‘wow’ them. These are the items that will typically not be missed if they are absent, but they will impress your stakeholders and will make your product stand out.

Where Kano starts to get interesting is when we plot the relationships among these different categories, as shown below.

The red arrow at the bottom of our graph shows our Baseline Expectations. Without these items, there is either no customer satisfaction, because the product does not exist, or we get customer satisfaction up to somewhere close to (but not quite at) neutral. Our Linear Satisfiers are items that can cause dissatisfaction if they do not exist, or are partially implemented, but can make our customers REALLY HAPPY if we fully implement them. Finally, our Delighters are things that make our customers happy, but will never result in them being unhappy. This is because Delighters are usually things that our customers did not expect – in a sense, you could describe them as ‘value-add.’

Combining MoSCoW and Kano for project and product management

Combining the simplicity of MoSCoW with the customer-centric view that Kano provides, gives us a robust lexicon with which to explore the mix of requirements we are delivering. Combining these models can improve customer satisfaction by effectively categorising and prioritising product features based on customer needs and expectations. In the example I gave further up this post, we saw that many items that are categorised as ‘Must Have’ in MoSCoW could be classified as ‘Delighters’ in Kano. Kano takes the opposite view and says that we should be getting the baseline expectations delivered first, but acknowledges these are unlikely to make our customers happy – merely make them less unhappy.

Mapping requirements to Kano gives us greater insight into our requirements and supports more informed decision making about requirement priority. For teams who are delivering in iterations, it will be essential to get a good mix of elements that ensure baseline expectations are met while continuing to improve our Linear Satisfiers and add a splattering of Delighters to keep our stakeholder excited. The combination is likely to vary throughout the lifecycle of the project, with the focus being on Baseline Expectations and Linear Satisfiers at the start of the project, with more Delighters being added to the mix later in the lifecycle.

How HotPMO uses this in practice

MoSCoW earns its keep in PMOs the moment a backlog fills up with self-declared Must Haves: it forces a sponsor or product owner to defend that label item by item, rather than let everything default to essential. We pair it with a simple capacity check across the wider portfolio, because a list that is well prioritised within one project can still crowd out higher-value work sitting elsewhere in the pipeline. That wider view, matching prioritised delivery against what the organisation can actually resource, is exactly the ground our project portfolio management work covers.