AgileIQ Blog

Initial Value and Delivered Value in Agile Software Development

  

 Email Article  

Tweet  

  

by Dan Williams

In a previous blog post, I expanded on the idea of Value by introducing the concepts of intrinsic and instrumental value. Software, I asserted, has no intrinsic value but only instrumental value. That is, software has no value in and of itself; rather, it is considered valuable based on its delivery of features to the user which they consider valuable. The feature itself may have either instrumental or intrinsic value, depending on what that feature or feature set accomplishes.

In this post, I want to discuss initial value and delivered value. Initial value of software delivered is considered to be its cost. When a person purchases an item or a service, they anticipate the delivery of value to themselves. In the case of a television set, I anticipate evenings of viewing pleasure with my wife as we watch British murder mysteries. The television has an instrumental value in delivering pleasure to my wife and me. The value I place on the television in the store is the cost of the set which I am willing to pay in anticipation of the value delivered later in my home.

So the value in the store is not only the instrumental value, which is anticipated, but it also has an initial value or cost which I am willing to pay.  The cost provides the starting place for value, both anticipated and realized. That initial value is not the instrumental value which holds the promise of value eventually received, or the delivered value which I will experience over time in my home and which has a non-monetary value. It is the start, not the end, of evaluation.

Initial value or cost is often the only hard metric captured for tracking purposes in software development projects. I suggest that delivered software measured over time is the missing metric which should inform the Product Owner as to whether the project achieved the promised results of profitability, market share, risk avoidance, etc. But who would perform this measurement? I believe it is the Product Owner. 

Measurement of these factors is a long-term effort, and demands the continuity of attention of the Product Owner. This responsibility must be made explicit and agreed to by the PO -- otherwise the opportunity to gather empirical data on whether our software development efforts are actually delivering value to our users will be lost and we will continue to rely on cost metrics to evaluate value.

To restate, organizations usually do not measure the long-term benefits of projects.  This results in Product Owners equating the cost of the project to its value, hence our traditional focus on project cost and schedule. Measuring benefits such as enhanced revenue or reduced costs over time cannot be the job of the project team due to the duration of the effort.  Thus it falls to the Product Owner to define, measure, and test to see if the intended intrinsic benefits were achieved to truly understand project success.

In my next post, I will continue to develop ideas around value and how, to whom, where, and when it is delivered.