Agile Software Development

In the absence of market facts, he who owns the compiler wins. © Steve Johnson

If you are on the customer side of a project (for example, being a Scrum Product Owner or a person above him) you might have experienced a situation, when you ask team for building features A, B and maybe C, and the build C, D and a bit of B, "because they thought D was more important for the user".

Theory

Scrum theory on the customer side is simple. Formulate your requirements in a list, team commits to what it can, implements the committed items during a sprint and in the end you accept or reject what they managed to come up with.

Ok, being a good product owner you don't separate yourself that much from the core team. You regularly groom the product backlog together with the team and during the iteration help the team understand what exactly you want, but the process still revolves around listing requirements and accepting/rejecting their implementation.

Different potential user groups and even users within the same group can have different opinions on the product features. The only way to see the high-level picture is to question many users and to gather some statistics on the user preferences. If the user opinions are gathered with the help of Kano questionnaires, the answers can be analyzed in a simple table.

One of the simplest ways of dividing the product features into must-haves, linear, exciters and even wrong features is to gather the potential customer's opinion with the help of the Kano questionnaires ( PDF ). Kano questionnaires include two questions for the every feature or group of features: the functional question "How do you feel if this feature is present?" and dysfunctional question "How do you feel if this feature is NOT present?"