# Calculating Earned Business Value For An Agile Project

[article]
Summary:

It is apparent that agility works, whatever that may mean. However, many software projects remain artifact-driven and waterfallish. Why is this? The most common excuses are that agility is too developer-centric, that it is too lightweight, and that feedback to business is hard to understand. In particular, many managers in larger companies miss their metrics. In this paper we address this last problem by defining a new metric, Earned Business Value (EBV), that replaces standard Earned Value Analysis (EVA) metrics, and can be calculated in an agile project. Using EBV, teams can gain better understanding of a project's progress and determine when and where to reallocate resources or change course.

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

## Pages

### About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.