9. Nov. '20
Photo by Ian Beckley from Pexels
As a product owner in agile projects, one is often faced with the simple but difficult question of which product features should be implemented first. The article describes how to use the Kano model to group your requirements to better prioritize them.
I was involved in a current IT project as an agile coach and we were faced with the challenge of building a software from scratch. We were busy collecting requirements, but were quickly faced with the challenge: Where do we start implementing? The agile answer to this question is simply "for what is most important to the customer". That sounded logical, but was difficult to put into practice. Why? Because in the past we didn't think about prioritization, but only talked about "finished products". Finished doesn't mean 30% or 40%, but 100%. But if I have to start somewhere, that doesn't help me. Methodically we are used to working with requirement specifications from classic projects - in agile (Scrum) projects we work with backlogs. At first glance, you might think the only difference is that the backlog contains a prioritization. But the differences go deeper:
Classical requirements and specifications
Backlog:
The question of business value now starts where we left off, above: What is business value for the customer? The Kano model groups customer requirements into three categories:
The car example also illustrates very well that features change categories over time. Many technological innovations, that were once performance characteristics, are now threshold attributes that are expected to be "standard" - e.g. ESP, airbags, power steering, etc.
The Kano model forced us to look through the lens of the customer. What are the threshold attributes here and what excites me? If you have these characteristics in mind, you can start with the basic characteristics, then the performance characteristics and then the excitement attributes. At the same time, we defined milestones in the project based on customer satisfaction. (Y-axis) to get a common understanding where and how we build the product step by step. Of course, these levels of satisfaction cannot be clearly defined, but they do force quantifiable values to be obtained, e.g. through surveys, and thus make the only thing that counts measurable: Customer satisfaction based on working software.