In neoclassical economics, the value of an object or service is often seen as nothing but the price it would bring in an open and competitive market. This is determined primarily by the demand for the object relative to supply. Many neoclassical economic theories equate the value of a commodity with its price, whether the market is competitive or not. As such, everything is seen as a commodity and if there is no market to set a price then there is no economic value.

While this is often difficult, I believe it is one of the underlying issues in the software development industry today. I’ve presented some tools to directly connect value to dollars in by blog post The Dollar Value of SaaS Features

I would love to hear your thoughts on this!

I wrote about the different story template in http://blog.nayima.be/2009/06/08/estimating-business-value/

I’ve talked with Chris about Feature Injection. Our approaches are similar, but we use different techniques to implement the approach. Feature Injection, Chris Matts and Andy Pols will feature in a future entry about how I’ve done business value modeling.

I’d like to point you at Chris Matts’ work on Feature Injection, which is very similar to the outline you’ve proposed here. Chris doesn’t write as much as I wish he would on this, so here’s a link to the article where I described it:

http://www.infoq.com/articles/pulling-power

You may also like his template for stories. I’ve found the rewording really helps:

http://lizkeogh.com/2008/05/14/rip-as-a-i-want-so-that/

This approach also plays very nicely with BDD and Kanban!

A colleague of mine just gave his takeaway from a lean perspective :
“User Stories Business Value Estimation == waste + waste (inventory + overprocessing)”
to which I replied with a not so lean translation :
“What is the f_cking most important stuff that we wanna see running ?”

By the way, it’s the kind of question that’s being dealt with when
building a storymap and making explicit the goals of actors using the software.
Which still leaves one additional goal, for the people building it :
get rid of the blind spots and learn about the product being built (incrementally)

Thanks for the post

Thomas

I dislike unsubstantiated theory: “Hey! Here’s a great idea! I think it will work and everybody should do it all the time, everywhere”

We’ll have to improvew it for next year.

On the theoretical sessions, I also agree, but we need to also have those. A balance is needed. As Davwe Snowden pointed in the panel: we need to know the theory if we are to have any hope of ever applying many of the techniques we talk about in the right contexts.

A challenge for next year is also to bring experience-based sessions, but with theory included