How to apply Earned Value Analysis on a Scrum project?

Question

I'm curious to learn how other managers apply EVA in software development running under agile techniques, like Scrum.

I do like the concept and I'd like to try it but I don't understand how to apply it when you don't track money (which is a case in Agile).

So EVA assumes converting project progress into money. Each task is estimated before actual work and after the work is done. With that one can easily calculate PV, EV and AC. It's easy to do in outsourcing environment, when you calculate hours spent on each task and multiply it by an hourly rate.

In agile there's no money, so what could be a parameter to measure PV, EV and AC?

I thought of SP estimates, but there's a contradiction I see. When the task is finished I can't say "well, we estimated it in 3 SP, but actually spent 5 on it". Scrum simply don't do that. And without this "spent" variable I can't really calculate AC, thus I can't use EVA.

How do you calculate EVA, when estimating in SP, but not money?

Answer 1

I'm not sure how much earned value management makes sense in agile methods. But it's not because you don't track money. There's no reason why someone shouldn't be looking at money, and no agile method prohibits it.

You can measure earned value based on completed work as well as actual costs, and the difference between these would give you cost variance. You should know your actual costs with certainty on a regular basis - it's the sum of costs including, but not limited to, things like the team's salary, tool licenses, vendor-provided services, and so on. An estimate of the value of the work can be provided by a product manager, sales and marketing teams, the client or customer, or a similar stakeholder.

I do think it's important to say that you may not be able to track value on a single unit of work level. It depends on how small your units of work are. Personally, I favor units of work that are the smallest thing that it makes sense to demonstrate and get feedback on. However, just because you can show it and get feedback doesn't mean that it's big enough to deliver to customers and users for use. So you need to understand when you complete and deliver one or more units of work that, together, add value.

What I don't see is a way to forecast planned value that makes sense. Since agile methods are best suited to complex or complicated domains with a lot of unknowns, uncertainty, and ambiguity, I don't see how you can forecast planned value much beyond your planning horizon. You can't forecast much beyond your planning horizon. If you can forecast planned value 8, 12, 24 weeks out or more, then your team should probably have a planning horizon of 4-6 weeks. Or perhaps you may want to revisit agile methods entirely, since such long-range planning is more indicative of the clear domain and the need to quickly respond to changes and uncertainty is lower, so the practices associated with agile methods may be increasing the overhead.

Even so, tracking earned value and actual cost alone may be a good start. You would be able to monitor the monetary cost of the work delivered by the team compared to the estimated value of that work. If the cost of the team is exceeding the value of the work, then it may be an opportunity to consider if the team should move onto more valuable efforts.