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?

  • Most agile frameworks have a fixed run-rate. You could consider Scrum Increments or Product Goals as milestones that earn value, but they aren't designed for that. EVA is a poor fit for iterative development, but you can always measure "where you are today" vs. "where you want to end up" and estimate earned value from the delta.
    – Todd A. Jacobs
    Commented Jan 16 at 16:00
  • Related: pm.stackexchange.com/a/16376/4271. Addresses agile release planning, but not directly applicable to EVA.
    – Todd A. Jacobs
    Commented Jan 16 at 16:03

1 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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.