Agile Zone is brought to you in partnership with:

Mike Cohn is a consultant and trainer who specializes in helping companies adopt and improve their use of agile processes and techniques in order to build extremely high performance development organizations. He is the author of Succeeding with Agile, Agile Estimating and Planning, and User Stories Applied for Agile Software Development. He can be reached through his website at Mike is a DZone MVB and is not an employee of DZone and has posted 21 posts at DZone. You can read more from them at their website. View Full User Profile

The Problems with Estimating Business Value

  • submit to reddit
I occasionally see teams that want to put an estimate of “business value” on each user story. They usually do this for either or both of two reasons:
  1. to be able to measure the amount of “business value” delivered to the organization, usually graphing this sprint by sprint
  2. to be able to prioritize user stories by comparing the business value of each story to its cost

There are, unfortunately, some problems with these practices.

First, the value of small bits of functionality are often intertwined. When we get features that are too small (as good user stories are), it is very difficult to put a discrete value on each. Economists call this hedonic pricing. The classic example is putting values on the individual components of a house’s value—size, location, view, etc. How would you value each of those aspects of your house? You can see more on hedonic pricing on Investopedia and this example of pricing clothes dryers shows how complex hedonic pricing can get.

Second, the value of a small bit of functionality can often be said to be the total value of the product. For example, what is the value of the left front wheel of a car? Well, since I don’t want a car without that wheel, the value of it is the total value of the car.

Having identified two problems with assessing the “business value” of a user story, let’s look at a problem with determining the cost of the story.

The Problem of Shared Cost

Finally, when attempting to put business value points on small features (such as user stories) there is the additional problem of determining the cost of the feature. There is often a desire to do some form of return on investment (ROI) analysis on features by comparing the business value points to the cost in story points. However, with small features it is often the case that the true cost of implementing a feature is the sum of the cost of implementing multiple smaller parts of the system, some of which (e.g., architectural work) may not be separately estimated.

For example, the cost of refunding money to a credit card purchase should include some of the infrastructural work done to accept credit cards in the first place. That cost, however, was likely estimated as part of the story to “buy the items in my shopping cart.” Failure to share the cost of this credit card processing infrastructure between both the purchase and refund stories will lead to incorrect ROI decisions.

As with hedonic pricing, this is something economists have wrestled with for years. A simple example is a cow raised and sold for beef and leather. How should the costs of raising the cow be apportioned between the user stories of “beef” and “leather”? We could say the beef cost it all and we get the leather for free but that would be no more correct than the opposite. The benefits (beef and leather) need to be considered together in comparison to the cost of raising the cow.

What Do We Do?

So does this mean that we should never assign business value to features and that we should forego ROI analysis of user stories? Not necessarily. But this type of analysis is best used at the level of epics (large user stories) and themes (groups of stories) because value and cost can be appropriately assessed at those levels.

Published at DZone with permission of Mike Cohn, author and DZone MVB. (source)

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



Benny Baggott replied on Tue, 2010/09/21 - 1:38pm

Mike, This is good insight and I can't disagree with any of it, in fact, I have seen evidence of it in our own implementation. However, I was taught to define user stories at the feature level and use that value among other things to drive what is included in a sprint. By this method we are supposed to ensure that we are working on the most important things in the backlog and maximizing the value that we provide to the company. If you assign value at the project or epic level, where it is easiest to do so, you run the risk of delivering features related to that project that are of less value than features of another project that are of greater value. How do you address that aspect of Agile/Scrum?

Emma Watson replied on Fri, 2012/03/30 - 5:14am

Agreed. We have done business value estimation with great success. I think what you’ve hit on is critical. Business value estimates work best with more course grained features and not individual stories.


Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.