Estimating Business Value

Posted by Chris Sims on Jan 04, 2010

Sections

Process & Practices,

Architecture & Design

Topics

Delivering Value ,

Agile ,

Agile Techniques

Tags

Measurement ,

Business/IT Alignment ,

Planning ,

Prioritization

The traditional agile approach to prioritization is that user stories of higher business value should be implemented before ones of lower business value. The concept is simple, but implementing it well relies on having a mechanism to assess business value. Pascal Van Cauwenberghe has recently described an approach to defining business value, called "Business Value Modeling", which may help.

In Pascal's article How do you estimate the Business Value of User Stories? You don’t., he asserts that there is a fundamental flaw in the assumption that the user story comes first, and then its business value gets assessed. Pascal proposes that a better starting point is with the question: "How do we find the User Stories that deliver the Business Values?" He goes on to suggest this approach:

• We first decide what values (or benefits) we want to achieve before launching a project or product
• Then we find and improve the business processes that deliver that value
• Then we find and improve the supporting business processes that make the value-delivering processes possible
• When the team needs user stories, we take the highest value processes and break them down into user stories at the right level of granularity for the team’s needs. The team pulls the stories, so we only generate a minimal set of user stories.

In a follow-up article, Pascal goes on to examine the meaning of the term "Business Value." He isn't satisfied by a single metric such as 'Shareholder Value', noting that there are usually multiple stakeholders with differing goals and needs. Pascal uses a process he calls "Business Value Modeling":

• Identify the relevant stakeholders.
• Identify their needs and goals.
• Agree on how we measure/test the achievement of the needs and goals.
• Select the (few) most important measurements and tests, the “Value Drivers.”
• Define the relationship between the Value Drivers.
• Use the Value Drivers to focus and prioritise our work, from start to finish.

A somewhat similar approach to assigning business value was described by Brandon Carlson in the article Story Prioritization in the "Blink" of an Eye. His approach builds up to the business value by first identifying the attributes of a feature that contribute business value. His team creates a list of such attributes that account for aspects such as: contractual obligations, market windows, customer impact, system health and corporate strategy. Business experts in each area then score each feature's impact on their particular area. Based on this input, a business value number is calculated for each proposed feature.

Once all of the stakeholders have scored his or her own attributes, the scores are tallied and the features with the highest positive impact to the product float to the top of the list. No debates (Ok, a few, but not like before), just numbers.... Since making the switch, we have witnessed noticeable improvement in the productivity of the [prioritization] meetings. The baseline priorities are set in first few minutes of the meeting and the total meeting time has dropped significantly, from an hour and a half down to 30 minutes.

Mike Cohn, in the various incarnations of his "Prioritizing Your Product Backlog" presentation, has taught a variety of techniques for assessing relative business value. These techniques include "Theme Screening", "Theme Scoring", "Relative Weighting", and "Kano Analysis". In one variation of this presentation, available on the Scrum Alliance website, Mike even shares a financial model that assigns values to themes (a theme being a collection of related user stories), in terms of Net Present Value and Internal Rate of Return.

In The Productivity Metric, James Shore found that having a way to measure business value was a prerequisite for creating a satisfying metric for productivity.

There is one way to define output for a programming team that does work. And that's to look at the impact of the team's software on the business. You can measure revenue, return on investment, or some other number that reflects business value.

When James revisited the topic in Value Velocity: A Better Productivity Metric?, he conceded that good metrics for business value are difficult to create.

While I still like this approach, it also has flaws. It can be really hard to measure value. Some types of work that are valuable don't lead directly to improved sales. Also, some of the causes of improved value are unrelated to the team's work....some types of stories don't provide value in the traditional way. What's the value of fixing a nasty crash bug? The entire value of the software? Or nothing at all? What about the value of fit and finish?

James ultimately suggests creating business value estimates, in a manner similar to the way agile teams create work estimates. Kelly Waters also recommends this approach in the article Measuring Business Value in Agile Software Development. Just as with story sizing, Kelly uses a Fibonacci scale to assign relative business value to each story.

In the same way as the development team estimates in points, the Product Owner decides on a business value for each item, relative to each other. The key thing here is that the estimated business value is relative, i.e. a feature with a business value of 2 is twice as valuable as a feature worth 1; a 5 is worth 5 times a 1, etc.... putting a business value in points against every item on the backlog allows you to calculate 'Business Velocity', i.e. how much business value (in points) was delivered in each Sprint. You could plot this on a 'burn-up chart', showing the cumulative business value delivered over time.

How does your organization measure business value? How does this impact the prioritization of the work that the developers do? Leave a comment and share your experiences or opinions.

1. Back to top

   perception index

   by toby young

   Chris, you might also take a look at the following...
   
   www.infoq.com/presentations/perception-index-sq...
   
   this handles the problem of quickly changing priorities on value... it also takes size estimates into account.

   Reply

2. Back to top

   Feature Injection (with a better name!)

   by Elizabeth Keogh

   This is very similar to Chris Matts' Feature Injection, in which the core stakeholders and incidental stakeholders define goals, which are split into themes or feature sets then features and finally stories. I introduced it back in May 2008, here:
   lizkeogh.com/2008/05/14/rip-as-a-i-want-so-that/
   
   The one difference I noticed is that in FI, we don't select the top value drivers; we select the absolute minimum needed to achieve the vision. I tend then to do the most risky things first, since learning is usually the constraint.
   
   My article on Feature Injection and BDD is here: www.infoq.com/articles/pulling-power
   
   and here's the Skills Matter podcast describing the tests associated with each level of detail here:
   skillsmatter.com/podcast/agile-testing/talk-4
   
   A case of convergent evolution?

   Reply

• Older >