Home | Login | Recent Changes | Search | All Pages | Help

EarnedValue

In another thread, EffectivenessAndVisibleReminders, Charles asked if Dwayne was doing Earned Value. I don't understand how to do earned value for software. I understand how to implement by feature, which is the only way I believe any project can calculate earned value. But I still have a problem. Even if teams implement by feature, sometimes you have to change something about an already-implemented feature. Maybe the customer says "You did what I asked but it's not what I want." Maybe there's an unforeseen complication with another feature. It could be anything -- but the key is the new work changes the old work.

So, I don't understand how to calculate earned value until there's a release, and it's quite possible the value will change as you proceed with the next release (whether those releases are iterations before a customer release or customer releases). What do you measure and why? -- Johanna Rothman 2005.06.04

Thank you for throwing in cases that mess up the whole earned value system. ;-)

Let me see if I am on the same track as you.

Suppose you are implementing a feature this month. Your team must complete five tasks to implement the feature. Each tasks is planned for 30 person-hours of work and all the people are paid $40 an hour (made up numbers so the math is easier).

This feature is worth 5 x 30 x 40 = $6,000 of value. When you complete the feature you have earned $6,000 of value. Now you can compare the value earned with what it actually cost you do implement the feature. If you needed 180 person hours instead of 150, you over ran your budget, i.e. you underestimated the difficulty of the task. The Cost Performance Index CPI=0.83 (CPI is the earned value divided by the actual cost, a CPI of 1.0 is right on, greather than 1.0 is better).

Now to your question, the feature is done, but the user walks in a says, "That's not what I had in mind."

Two of the things you can do:

(1) Keep working on the feature until you satisfy the user. Suppose you do this and you worked an additional 100 person-hours. Now you worked 250 hours vice the 150 hours you planned. The feature has cost you 250 x 40 = $10,000, but its value is still only $6,000. The CPI is 0.6 - that's really bad.

(2) You call the first delivery version 1.0 and the requested enhancements version 1.1. You plan the work for version 1.1 and estimate you will need 5 tasks, 20 person-hours per task, $40 per hour salary. Version 1.1 has a value of $4,000. You do the work and deliver version 1.1 with 100 person-hours of work. It costs you $4,000 and you deliver $4,000 of value. Good job.

Alternative (1) above implies that you better know what you are doing before you start working.

Alternative (2) above implies that you (and your bosses) understand that things can change in software and you better have some extra money lying around to cover the expense of those changes.

I hope this example makes some sense.

DwaynePhillips 4 June 2005

The first problem is "value". In Dwayne's example above, I assume the customer said "Yes, I'll pay $6,000 for that feature." But is that really value? What if the customer would really pay $12,000, but likes the original estimate? What if in running over, the customer would happily up the payment to $10,000 (while making a sad face)? The CPI suffers, but value is still being delivered. As I look at EarnedValue, I often see the original cost estimate (or an estimate that's been beaten down by management) conflated with value.

One of the good aspects of EarnedValue is that the development team focuses on items that are of value the customer (or customers) in some prioritized order. But prioritizing features doesn't required EarnedValue. Agile methods prioritize. And in an environments where you learn as you go, and where the customer learns what they really want as they get what they initially asked for, does CPI make sense? I don't think so, particularly if CPI ends up being part of the compensation formula.

The second problem, in Enterprise application development at least, is that "value" is very, very fuzzy. The best numbers I've seen come out of Sales, in the form of "We need the product to do X in order to make a $Y,000 sale." But often X is what the Sales folks thought they heard the prospect say, and once the development team builds X and the prospect sees it, the prospect clarifies that they really meant X'.

In my world, this is normal. But it makes for a very unstable basis for doing EarnedValue.

--DaveSmith 2005.06.04

I believe in agile methods people use the term "velocity." As I understand it, velocity does the same thing as earned value. You make an estimate, compare it to your actuals, and adjust your future estimates. If your earned value indicies are consistently 20% under, you adjust your future estimates by 20%.

DwaynePhillips 5 June 2005

I've heard of at least one XP project where the stories are given estimates in dollars of what their value will be, and they schedule the highest-valued stories first. All XP projects are supposed to do this, but usually the value of the stories is not stated in dollars and their value-estimates derived from expected sales figures (with hard data to justify those figures).

KeithRay 2005.06.05

"Velocity" is, roughly, the amount of estimated work (in some arbitrary unit of measure) that a team accomplished per some unit of time. Velocity is a backward-looking measure that's used for forward planning. For example, if my team got 12 "units" of work done during the last iteration, we'll plan for no more than 12 units of work for the next iteration (more work may get added if we're ahead of plan, or some will get removed if we're behind. No matter, the cap is 12 units). After the next iteration, velocity gets recalculated. Velocity has a short shelf-life.

As long as we're estimating consistently--a fanciful but necessary assumption--the estimated to actual ratio doesn't matter. The quality of estimations stops being a moral issue. The focus shifts to how much work the team actually gets accomplished. (We worry about our estimates inside the development team, but it's an internal issue.)

XP's velocity is independent of the "value" of the tasks being performed. Our product manager (acting as a proxy for our customers) worries about value. He keeps a spreadsheet of estimated dollar values for tasks, and does some math using dollar value vs. estimated effort to help him prioritize, but the development team rarely sees that spreadsheet. All we care about that the work in front of us has been prioritized.

Agile (as a superset of XP) adopts the Lean Production measure of "throughput", which joins velocity and value back together by talking about how much value a team is producing per unit of time or cost.

--DaveSmith 2005.06.05

I do like the idea that if the product is good enough to release, you get to claim something for this release and something for the next release. -- JohannaRothman 2005.06.07 (at least in my time zone it is)