Agile Software Development

Agile teams try to avoid the over-detalization of the customer requirements. In many cases the initial requirements are specified as loosely as in one sentence. In order to keep focus on the real customer demand (and not on what dialogs he'd like to see) the feature requests are often expressed in a form of "As a , I want [so that ]". For example, "As a network administrator, I want to monitor the most active nodes of the system so that I was able to easily balance the load". This form of requirement works very well until you start to work on it. It allows for capturing the original user need, while delaying the implementation specifics as long as possible, so that the team was able to work on it with as much information as possible.

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.

According to the Standish group research on average 45% of a software features are never used and only 20% of features are used always or often. It means that on average you could develop two times simpler product and sell it for the same price. Potentially gains can be even bigger, for the enterprise scale systems two times simpler product often means four times shorter schedules and ten times simpler integration and testing.

There is no other way to discover what features would be actually used, than to ask the real or at least potential customers, preferably after letting them to try some features live. One of the tools for aiding the feature categorization is the Kano model of customer satisfaction.