Agile Software Development

Working through Scope with MoSCoW and Kano

Managing scope is one of the perennial challenges of running a project. Where agile projects are concerned, many rely upon MoSCoW to keep scope in check. However, John McIntyre suggests in a post for HotPMO! that MoSCoW may not satisfy every scenario by itself. Some extra help may be in store, in the form of Kano.

When East Meets… East

MoSCoW categorizes all requirements as one of four things: must-haves, should-haves, could-haves, and won’t-haves. Must-haves are critical to the project and must occur in the given time window. Should-haves might be equally important, but they do not need to be completed in the current time window. Could-haves are nice perks that offer improvements at nominal cost if time permits, but they are not crucial for project success. And lastly, won’t-haves are requirements that can simply wait for later.

McIntyre takes a critical eye specifically at how people choose to implement MoSCoW. He says to suppose sales and marketing have some requirements for the team that are promising high-value sales and conversions:

Based on our MoSCoW ranking system we would categorise these based on their ability to deliver great and immediate business benefits and would therefore categorize 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, whilst anything that can be put off, ends up being deferred indefinitely. A common pattern is for work such as refactoring, maintenance and efficiency improvements being put off, in favor of new features.

To combat this, McIntyre recommends complementing MoSCoW with the Kano Model of Customer Satisfaction. Kano can divide requirements three ways: into baseline expectations, linear satisfiers, and delighters. Baseline expectations are requirements in the truest sense—needed for a product to succeed. Linear satisfiers are requirements that occur along a “sliding scale” according to quantity present; Kano gives the example that more website speed is always a good thing, and less website speed is always a bad thing. Finally, delighters are items that, while not critical, will “wow” people and help pronounce a product.

McIntyre believes that combining MoSCoW and Kano provides some new insights. For instance, one might find that some “must-haves” fall into the “baselines expectation” category while others fall into the “delighter” category. Fulfilling the baseline expectations will minimize the odds of stakeholders being unhappy, and fulfilling the delighters will maximize the odds of stakeholders being potentially happy. This is an important distinction to keep in mind, and it will inform better project decisions.

For some useful graphs that illustrate very well how MoSCoW and Kano pair up, you can view the original post here:

Show More

We use cookies on our website

We use cookies to give you the best user experience. Please confirm, if you accept our tracking cookies. You can also decline the tracking, so you can continue to visit our website without any data sent to third party services.