Calculating Earned Business Value For An Agile Project

Earned Value Analysis is a powerful method often used in "standard" project management, and there are three basic metrics in EVA. The first is Budgeted Cost of Work Scheduled (BCWS), which is the baseline cost up to the status date you choose. The second primary metric is Actual Cost of Work Performed (ACWP), which is the actual cost required to complete all or some portion of the tasks, up to the status date. And the third basic metric is the Budgeted Cost of Work Performed (BCWP), which is the value of the work performed by the status date, measured in currency.

Earned Value Analysis mostly consists of combining and manipulating these three metrics in various ways. Unfortunately, both BCWP and BCWS are not metrics that exist in agile projects, as they require a detailed, up-front plan to compare against. So, what are we to do?

The Goals
In order to solve this problem, we need {sidebar id=1} to know why Earned Value Analysis exists, so that we can figure out how to replace it. When the business asks about EVA it is usually asking about progress on our project: how we're doing and when we'll be done.

In other words, the business is are asking for information about the value of the product - how much value is being provided? So we need a metric that measures how "done" we are from a business perspective. We'll call our new metric Earned Business Value (EBV).

Features and Stories
In order to discuss EBV, we need to have the notions of feature and story.

Feature
A feature is something about our project and/or product that we advertise or sell, and that we must do work on to provide. Typically, our product (or release) is described as a list of features, such as:

• Allows Users to Update Customer Information
• Supports the XXX Claims form
• Added "Updated Customer Info" Reporting
• Improved User Interface
• Faster Rendering of Reports
• Improved Security and Protection against Hackers
• and so on...

Features are implemented in the product by working on stories, and the stories are said to belong to the feature.

Stories
A story is the fundamental unit of value, requirements, and work that is visible from both the inside and the outside of the project. Stories are used as the interface between the business and development sides of the project.

Stories are important since they are the smallest units of value that are managed. Stories have been described as "promises for conversation" by Ron Jeffries[2], and I agree wholeheartedly. Basically, a story consists of four things:

• 1. Description: a short description of the goal to be achieved.
• 2. Size: for rough estimation purposes. Units such as Story Points (SPs), T-Shirt sizes (S, M, L, XL), Days, and even gummi-bears, have been used.
• 3. Validation Criteria: what it means to be "done" with this story. This is probably the most important attribute, as being "done" is what allows the team to claim the value of the story.
• 4. Business Value: not all stories have business value, but the ones that drive development do. This is what we are trying to calculate.

Stories are of various types, and the following are example stories for a "Update Customer Information" Feature:

• Determine what the stakeholders want to happen (analysis story, done when we have a validated user scenario, screen mockups, and success post-conditions);
• Develop the main execution flow (development story, done when we have verified tests that pass);
• Determine alternative flows, and what we want to do about them (analysis story, usually time-boxed);
• Develop alternative flow X (development story, one for each alternative flow); and
• Stress-test the feature for 500 simultaneous users (test story, done when we have a validated testing regimen that passes).

Work Breakdown Structure
Management needs a view of the work that shows the "big picture." Luckily, standard project management has such a structure already invented for us - the Work Breakdown Structure (WBS) - which is a "deliverable-oriented grouping of project elements which organizes and defines the total scope of the project.[3]" Many agilists cringe at the mention of a WBS because of its ‘high ceremony' connotations, but I use it merely as a way to categorize or organize my stories into areas. The WBS that I use organizes the work into three main areas:

• Product - work that is directed to actually producing the software product;
• Team - work that allows/enables the team to be able to produce the product; and
• Business - work that allows the business to market, sell, install, or deliver the product to users.

Each project is different and the actual structure of the WBS (what rollup buckets there are) is a business matter, because the WBS is primarily used as a tool for organizing the work in ways the business can understand. The stories that live at "the bottom" of these buckets define the work being done. A WBS for a fictional development project appears at Figure 1.

Figure 1: Sample WBS

Let's use this WBS to calculate business value.

Calculating Business Value
We do this in a straightforward way and provide the business value of any WBS bucket, including stories (the ones at the bottom). We note that the Business Value metric we are calculating is actually a percentage, not a dollar value.

First, we assign additive weights to the buckets of the WBS, which represent features and other organizations of stories. In the simple view in this article, we only get business value in our sample WBS by either putting features in the code or by doing something that lets the business market or sell the product - there is no business value in other parts of the WBS.

I'm using relative weights on the WBS here - each WBS bucket is compared to its siblings - and the following WBS with weights is telling the following story:

• Our Product Leg is worth 3 times as much as our Business Leg, and our Team leg provides no business value;
• Adding features to the product supplies business value, but modifying or cleaning up code that already works does not;
• Improving the User Interface is the most important feature, worth 1.5 times as much as being able to Update Customer Info; and
• User Documentation is the most important business bucket, but is still not worth very much compared to any of the features.

It is up to the business, or customer, to assign the weights to the WBS legs and stories - this is not a technical matter. There is no guaranteed formula; there is only the requirement that the weights be additive. For example, is "Team Training" something with business value or not? I don't know, it's up to your project. Typically it doesn't provide value if paid for out of project funds, but might if paid for out of overhead (training) funds. Our WBS (with weights) could look something like Figure 2.