Subscribe to AgileIQ via email

Your email:

Subscribe to our Newsletter

siq newsletter 180

AgileIQ Blog

Current Articles | RSS Feed RSS Feed

Initial Value and Delivered Value in Agile Software Development


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.

Initial value and delivered value in Agile software developmentIn 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.


I totally agree. The implication here is that a) the Product Owner has time to craft and track such measurements, and b)writes and prioritizes the necessary stories when measurement requires support of the software itself. Even in organizations that have Product Managers, this often doesn't get done. But it is something that management desires. Is this part of "definition of ready"?
Posted @ Saturday, November 17, 2012 7:02 PM by Linda
I think the title of this post is somewhat misleading. What you're talking about here is benefits realisation, which is equally applicable to every project regardless of methodology. It's not just applicable to Agile projects. 
I think the statement, "organizations usually do not measure the long-term benefits of projects" is wrong - unless you are applying it specifically to Agile environments. Measurement of benefits is an intrinsic part of traditional sequential project models; but not of Agile models. Many businesses which follow the latter do not even track project costs, so even if they DO measure benefits they have no datum against which to compare them! 
Any business which consistently fails to measure actual benefits against planned benefits will surely soon become an ex-business... and without even understanding why.
Posted @ Monday, November 19, 2012 4:56 AM by Jim
On Jim's post benefits realization is certainly a significant part of value delivered, but may have nothing to do with the concept of intrinsic value, so I stick by the title. Also to Jim's point on my being 'wrong' concering "organizations usually do not measure the long-term benefits of projects", I question his use of the term 'wrong'. This behavior has been my continual obserbation in companyies where I have done traditional project management and various agile methods as well as being discussed in blogs and books so how wrong? I grant the behavior of companies not tracking value/benefits is short sighted, and possibly disasterous, but there it is.
Posted @ Wednesday, November 21, 2012 1:30 PM by Dan Williams
But the title of the post is not about "intrinsic value," it's about "delivered value." In other words, post-delivery benefits. 
My point was merely that your title specifically referred to Agile projects, whereas the principles and methods of measuring value are equally applicable to all projects, regarding of development methodology. There's no unique way of measuring benefits on Agile projects, as opposed to traditional projects. That's not to say that this article shouldn't have appeared on an Agile blog! 
My use of the term "wrong" should be taken as it is generally understood. In "traditional" (ie. non Agile) projects, the whole thing is usually based around a business case, which lays out the expected benefits. It's these predicted benefits that provide the go/no-go decision for the project, and the post-project benefits assessment that triggers project closure. 
A formally structured project lifecycle specifically documents this post-project benefits assessment phase. In the case of a supplier organisation, it's usually so simple as to be almost invisible: "Did we overspend, did we get paid, what was our overall margin?" (ignoring strategic aims, which I grant are often overlooked). For internal projects, such as upgrading a transport ticketing system, the process is more involved and there are confounding variables that need to be corrected for... but in my experience the evaluation still occurs to a lesser or greater extent. 
Because of the nature of Agile projects, oftentimes costs aren't even tracked, so comparing benefits to costs becomes difficult, if not impossible. That's not to say that the Agile methodology precludes cost tracking etc., just that it's not an intrinsic part of the process. 
It seems to me that we can chalk our disagreement on this up to different experiences. I think the major points you make in your blog post are valid and valuable, and I agree with them completely - we absolutely should be considering delivered value. The statement over which we disagree is incidental.
Posted @ Thursday, November 22, 2012 4:48 AM by Jim
I somewhere feel that example of TV sets doesn't relate to the software development.
Posted @ Sunday, December 02, 2012 2:59 AM by Ncover
Referencing Jim's second blog post I am glad we agree and he's right the title is about initial and delivered value not 'intrinsic' value so thanks. Even though tracking value or benefits delivered is not an explicit part of the scrum method, I think it fits within the Agile values so why not add it? 
I am of the school that scrum is additive so we can add not remove from it. Lets not do away with standups but we can add cost and value tracking.  
thanks Jim
Posted @ Monday, December 03, 2012 10:54 AM by Dan Wiliams
I think the TV example is OK because we are talking about perceived 'value' and doesn't that fit all products and services? 
Posted @ Monday, December 03, 2012 10:56 AM by Dan Williams
Comments have been closed for this article.