–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 prioritizing scope (or stories) is a technique called MoSCoW that was developed by Dai Clegg and later adopted by DSDM.
MoSCoW prioritization
The MoSCoW method assets that all requirements are essential, but they should be ordered to deliver the most significant and most immediate business benefits early. 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 labeled 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 labeled 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 labeled 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 labeled 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.
The problem with MoSCoW
The problem with this prioritization 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 categorize 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 recategorized 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 typical pattern is for work such as refactoring, maintenance, and efficiency improvements shelved in favor of new features.
How can Kano help?
In the 1980s, Noriaki Kano developed the Kano Model of Customer Satisfaction. Using the model, we can divide requirements into three categories: Baseline Expectations, Linear Satisfiers, and Delighters.
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
Combining the simplicity or 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. In the example I gave further up this post, we saw that many items that are categorized 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.