Monthly Archives: November 2014
Sale on Agile Textbook
Happy Holidays! Our Introduction to Agile Methods textbook is on sale at the InformIT website.
Through Saturday, 11/29
Please use this link and use discount code BF2014
Sunday and Cyber Monday (12/1)
Please use this link and use discount code CM2014
Details: save 70% off featured video and 50% off all other eBooks and digital video training! Sunday, November 30 – Monday, December 1, 2014 (expires 11:59 p.m. EST on 12/1)
Prioritization – Part 3: The Kano Model
Being a Product Manager and an Agile enthusiast, I spend a lot of time and energy working on prioritization. It is both an art and a science to make sure that you and your team are working on the most important thing. The first in this blog series on prioritization answered the question “Should we do this at all?” and the second shared different tools to help with prioritization, specifically MoSCoW and the Risk-Value Relationship. In this blog, we will tackle the Kano model, which holds a special place in my Agile story. I first learned about it when I was doing research for our Agile textbook. It then found its way into Businessolver and was a part of the story regarding how we addressed our Product Roadmap. Very cool.
Kano Model Explained
First introduced in the 1980s by Professor Noriaki Kano, it is a great tool for Product Managers to use when assessing different kinds of value. The vertical axis represents satisfaction. The higher you are, the more satisfied you are – one might say ‘delighted’ to put it into Businessolver terms. The horizontal axis represents how well something is done.
Source: Businessolver
Looking at the grey line first, these are basic needs – the ‘must haves.’ Thinking in terms of a hotel experience, we expect there to be hot water. Hot water is table stakes for a hotel experience. If you don’t have hot water, meaning the establishment didn’t do it well, then you are highly dissatisfied. However, if the hotel did have hot water, meaning they performed that function very well, it does not delight you. It is expected, so when done well, it doesn’t even register in your mind.
The blue line represents performance needs. This could be the check-in process at the hotel. It has the opportunity to dissatisfy – if the lines were long, the desk clerk inefficient or your room wasn’t ready – those circumstances could be very disappointing. Conversely if they recognize you when you walk in and you are greeted with speed and efficiency, then you might be pleasantly surprised, heading towards delighted.
Prioritization – Part 2: MoSCoW and Risk-Value
As introduced in the first blog, prioritization is difficult. The first and most important question is “should we do this at all?” Once you determine that an effort is worth doing, we have to figure out where it falls relative to the other things in the queue. There are a number of tools that we can use in this effort.
MoSCoW
The first tool in our arsenal is from Dynamic System Development Method (DSDM) and it is an acronym for Must have, Should have, Could 
have, Want. The technical definition for each category is as follows:
Must have: all features classified in this group must be implemented, and if they are not delivered, the system would simply not work.
Should have: features of this priority are important but can be omitted if time or resources constraints appear.
Could have: these features enhance the system with greater functionality, but the timeliness of their delivery is not critical.
Want to have: these features serve only a limited group of users and do not drive the same amount of business value as the preceding items.
To put MoSCoW in action, we pull a reference from our book, Introduction to Agile Methods. In this example, we are looking at the payment methods that could be offered on a new eCommerce site.
Must have: ability to accept Mastercard and Visa
Should have: add American Express and Discover
Could have: add ACH payments for transactions directly through banking institutions
Want to have: add gift cards
By understanding where each feature falls relative to the MoSCoW parameters, the prioritization is much easier.
