It's all about Value, or is it? And if it is all about Value, what is it?

May 22, 2009 by Jack Milunsky

Introduction

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 it? 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.

Kano Model

Value, from a stakeholders' point of view, differs from individual to individual and from organization to organization depending on their goals. 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.

Permalink