Agile Zone is brought to you in partnership with:

Jack has posted 23 posts at DZone. View Full User Profile

The Kano Model - Measuring Agile Value

09.21.2009
| 5511 views |
  • submit to reddit

In all the Scrum literature, there is much rhetoric on focusing on delivering value but there is very little explanation on how you calculate it. Exactly how do you calculate value? I came across an interesting article by Ryan Shriver called "Measurable Value with Agile" where he talks about delivering the right things by choosing tasks based on a cost/benefit analysis, and then delivering those things right with the selected agile method of your choice. Value is then calculated by measuring it via a defined set of identified targets, constraints, and benchmarks. Although I do agree that measuring performance is important, there is still a major problem; if business value can only be measured once a product/feature is delivered, how do you know which user stories to work on first and which ones to avoid? Sure a cost/benefit analysis may be an easy way to determine which tasks to focus on, however, the value of that task is yet to be determined. You can do a cost/benefit analysis, choose the "best" user story based on that analysis, and still deliver a feature that has absolutely zero value. So how do we offset this?

Other methods

There are numerous other methods that have been applied to calculating business value to base decision-making on such as financial prioritization, calculating NPV, shareholder value, the list goes on. However, I find that these methods all suffer from the same problem as a doing a cost benefit analysis. I haven't found a consensus as to exactly how to derive business value prior to implementation because of how subjective the perception of value is. Value, from a stakeholders' point of view, differs from individual to individual and from organization to organization depending on their goals.

Kano Model

In my opinion, the method to derive a number that comes closest to actual value is done by assessing themes (i.e. features) based on the Kano Model of Customer Satisfaction. According to the model, separating product features into the following categories can provide valuable information on how to prioritize work: threshold (or must-have) features, linear/performance features, and exciters/delighters (Mike Cohn, Agile Estimating and Planning, 2006). The relationship between customer satisfaction and degree of feature implementation can be found on the Kano model graph.

Business value alone may not cut it

So the more of these features that are implemented, the greater the customer satisfaction. And the way to assess the features based on the Kano Model is to survey users and customers directly and tallying up the results. Once customers or product owners tell you what they want and you develop the features based on those answers, there should be very little discrepancy between the estimated value and the actual value delivered. This is an overly simplified explanation of the theory so if you would like to read more about the Kano Model, I would suggest you read Agile Estimating and Planning by Mike Cohn. But I guess the main point that I'm trying to make here is that, although you can estimate business value, you can only truly derive business value once that feature/product has been delivered and feedback is provided (i.e. based on revenue, achievement of goals, etc). So trying to make an effective decision based on calculating business value alone, to me, is absolutely meaningless.


Written by Jack Milunksy - COO at Brightspark, certified ScrumMaster and Co-founder of Agilebuddy (Agile project management software that lets you easily Create, Estimate, Plan and Track your software development projects). For great Agile tips follow Jack at: www.twitter.com/agilebuddy. To get more info on Agilebuddy please visit: www.agilebuddy.com

var addthis_pub="agilebuddy"; Bookmark and Share

Published at DZone with permission of its author, Jack Milunsky.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)