Estimating Business Value

I have written before about my concern about the meaning of "Business Value". As a follow up I would like to suggest a new strategy for Product Owners that should lead to a more consistent and transparent approach to the prioritisation of User Stories based on Cost and Benefit.

First of all, an organisation should define "Business Value". There is no getting away from this. It should not vague or unclear. Agile development aside, an organisation that defines Business Value is likely to be a focussed organisation that gets the right job done at the right time! The team as a whole is more likely to have a positive feeling about proposed work if it demonstrably has Business Value and is not just the latest hot potato! My suggested starting point for a definition would be:

"A User Story has Business Value if it:
  • Meets a minimum requirement to meet basic user expectation; or
  • Makes the product more strategically competitive; or
  • Makes the organisation more strategically competitive; or
  • Is a popular feature that will generate revenue; or
  • Is a feature that will reduce costs"
The list above is in order of importance. A product must first meet the basic expectations of the user and it must jump the minimum barriers to entry for a particular industry. Then it should seek to become strategically competitive or make the developing organisation more competitive. Finally the product should have the features required to generate revenue or improve the bottom line through reduced costs.

Every organisation will have its own definition of Business Value customised for its own market, people, political situation etc.

From here on in, the Product Owner should have enough information to relatively estimate the Business Value of a User Story. For example, adding a social networking feature to a Scuba Diving club web site could be strategically important. Interestingly, the Business Value of a User Story may change over time. For example, if all Scuba Diving club web sites have social networking features then it becomes a minimum requirement of the user rather than a strategic User Story that will make the product more competitive.

I would suggest that the Product Owner uses the same scale as the development team uses for Story Point (Cost) estimation to estimate the Business Value. This then allows the Product Owner to perform the trade-off between Business Value (Benefit) and Cost to determine the priority of the User Story.

I am not suggesting any maths (e.g. weighted averages etc) to do any of this automatically. I think that the gut feel of the Product owner based on the Business Value and Story Points should provide enough for the prioritisation to take place.

It is also worth noting that this approach does not add any additional effort to the Agile process. All it does is formalise the process.

posted @ Thursday, July 03, 2008 2:57 PM

Print

Comments on this entry:

# re: Estimating Business Value

Left by Rafael E. Santos at 7/27/2008 10:50 PM
Gravatar
Finally, I had a chance to read your blog, Nick. I agree with the general statement you are making in your posting. Specifically, the importance of an organization to have a clear understanding of what is business value in their context.
I do have an issue with how you are separating Business Value from cost. I think you are confusing these concepts in this posting. In essence, you are saying Business Value is the same as benefit. I understand the confusion because I was there not long ago. I think BV for me is the combination of both benefit and cost. If the cost of something is higher than the benfit then there is no BV. So, if I were to make a recommendation it will be that the product owner defines the benefit and the team defines the cost and from there we get BV. In a larger organization it might be more complicated, because the PO might not be able to define benefit on its own.

I am not sure you can use the same scale (assuming we are talking about story points). In my case, I think you need to find a way to take them both to money (economic value actually). I know some people disagree with this approach, but it eliminates a lot of confusion if you are able to come up with a money amount. Can we find out how much a story point for a specific team costs? I think we can get close enough. You can easily approximate the number in every sprint if needed. If you get the salaries of all involved plus location costs (electricity, etc.) we can come up with a cost per story point. As the team gets better the cost of a story point should go down (increase in productivity).

Anyway, I think we are in general agreement. The only problem is: Where is the rest of the organization? That I do not know.

Your comment:



 (will not be displayed)


 
 
 
Please add 1 and 6 and type the answer here:
 

Live Comment Preview:

 
«August»
SunMonTueWedThuFriSat
272829303112
3456789
10111213141516
17181920212223
24252627282930
31123456