Is Agile’s Velocity Like Earned Value?

    The use of Earned Value (as defined in ANSI/EAI-748B) is a mature process for assessing the performance of projects in many industries - government, aerospace, defense, construction, large IT (SOX and CobiT compliance).
    Velocity is a metric used in agile software  projects to assess the performance of the development team.

Are They Related in Some Way?
    The answer probably depends on who is asking. For the EAI-748B specialist the answer is probably no. For the agilest the answer is probably Maybe. Several agile thought leaders have tried to make the connection. But this turns out to be a difficult task in the end for a simple reason:

• There really is no motivation for Earned Value from the point of view of an agile software development project.

In the absence of a compelling motivation, apply EV probably has no value. Even in the government (meaning civil), defense, and construction business, applying EV takes work. Earning back the value from Earned Value needs to be well defined in terms of cost and schedule management. Since agile projects are not directly focused on cost and schedule, but rather on the incremental delivery of "value" to the customer, applying EV needs some care.
    By the way, the units of measure in the agile vocabulary of "value" are rarely defined. They are left up to the customer. And the units of measure of velocity are arbitrary - kumquats are as good as dollars.

What is Earned Value Really?
    There are many popularizations of Earned Value in the project management literature. I come across erroneous definitions all the time. And I've given up responding to commercial article, BLOG posts and forum emails. It's a losing battle.
    But here's a simple concept from PMBOK®

Earned Value is a method for measuring project performance. It compares the amount of work that was planned to be done by a certain time with the amount of work that was actually done by the same time to determine of the cost and schedule performance is at the levels planned for that same time.
The work accomplished at that point in time earns it's budgeted value - the "earned value."

It's that simple, but at the same time subtle.

1. There needs to be a "planned value." The Budgeted Cost for Work Scheduled (BCWS). This requires a pre-definition of what the Planned Value will be. Creating the BCWS requires someone - the project manager, the Control Account Manager, the Work Stream Manager - someone define how much the work will cost in dollars. This "budget spread" is then baselined before the work starts.
2. The "earning" of the earned value is a calculated value. BCWP = BCWS x Percent Complete is the simple way.
3. The definition of Percent Complete is now the issue. Agile has a nice way of doing this. Look at what was produced at the end of the iteration. In the best case Earned Value uses a Physical Percent Complete metric as well.

So Where's the Gap Between EV and Velocity?
    Velocity has two metrics

1. Story points planned for the iteration
2. Story points completed for the iteration

Earned Value has three metrics

1. The Planned Value (PV) or Budgeted Cost for Work Scheduled (BCWS)
2. The Earned Value (EV) or Budgeted Cost for Work Performed (BCWP)
3. The Actual Cost (AC) or Actual Cost for Work Performed (ACWP)

There are some other measured needed for Earned Value

1. Budget at Completion (BAC)
2. Estimate at Completion (EAC)
3. Estimate to Completion (ETC)
4. Cost Variance (CV) = BCWP-ACWP
5. Schedule Variance (SV) = BCWP-BCWS

Notice that schedule variables do not have cost in there expressions.
So's What's the Problem?
    The first "gap" between velocity and Earned Value is velocity has only two variables. In the EV vernacular velocity is a measure of the "level of effort," consumed by the consumption of resources.
     With EV all three variables are needed. Two are independent (PV and AC) and one is calculated (EV).
    It's the comparision between Planned Value and Earned Value that is similar between Velocity and EV. But since Velocity doesn't measure the Actual Cost in any direct way there is a gap there. Velocity assumes the Actual Cost is constant. This is also a definition of Level of Effort.
    Bit a more subtle problem exists in Velocity. The Planned Value and the Earned Value are quantized in Story Points. The Story Points are assigned during the planning session at the beginning of the iteration. The units of measure are arbitrary by design, but being arbitrary they may or may not be connected to  business value. Business Value is most often measured in Dollars. And this is where the gap opens.

• What is the dollarized value of a Story Point?
• Are all story points worth the same unit of measure?
• Is the variance in Stories and their Story Points narrow enough to be used in forecasting future performance?

These questions probably need an working example to be answered. But it's the forecasting of future performance based on past performance that is the primary role of Earned Value. Agile woudl say "past is future." Velocity measures yesterday's weather. In Los Angeles, yesterday's weather may be tomorrow's weather. So weather reporting is nearly the same as weather forecasting.

Performance Based Earned Value
    In Earned Value this is sometimes the case. But Earned Value adds another variable - Technical Performance Measures (TPM). These are measures of performance. For example, how much should the spacecraft weigh at the Preliminary Design Review (PDR)? It meets it's TPM is the mass is within +/- 20% of target launch mass.
    When TPM and combined with EV the ability to forecast future cost, schedule and technical performance results.

In the End Velcoity Means?
    If you're searching for the connection between Velocity and EV it's at the Level of Effort concept. Velocity is a useful concept of agile teams. It defines classes of work. It assigns a measure to the effort needed to complete that work. It measures how much work was accomplished.
    But it does not measure "value" in any units meaningful to a business - dollars

Got something to say?