Earned Value in an Agile Environment

In interviews for Agile Coaches and Scrum Masters, I always ask the question, “What is the place of Earned Value in an Agile environment.”    There is no right answer, but I am curious how people are thinking to approach the melding of Agile with traditional data/metric driven project management. The answers are varied, ranging from well thought out responses to completely blank stares.

The blank stares are the interesting ones.  They fall into two camps: 1) those that know what Earned Value is and are confused why a Waterfall/PMPish metric is even being discussed in an Agile shop, and 2) those that have no idea what Earned Value is because they are so focused on the “Agile” nature of project management.

What is Earned Value?

Per the PMBOK “Earned Value (EV) is the actual value of the work completed so far at a specific date.”  Here is an example:

I am going to make cars.  Each completed car is worth $10K.  I am planning on creating 12 cars, starting in January, at the rate of 1 per month.  In March, I have completed 1 car. 

In this example, I have only finished a single car, meaning my EV is $10K.  EV itself does not care about the actual dates, plans, if I am behind, etc.  Those are other metrics such as Schedule Variance or Schedule Performance Index.  EV in of itself does nothing but tell you, at this date, this is what I have earned by performing work.

Why use Earned Value?

Software projects are hard to estimate thus, Agile being a great solution to the risk involved.  If you are ahead of your plan, or behind it, it is very difficult to gauge or forecast this because there are so many unknown unknowns in software development, particularly when R&D is playing a huge role.  EV lets us at least have a solid number on the value of what has been delivered so far.  In waterfall, we can determine this number by having a value on specific milestones.

Flemming and Koppelman [1] asserted that “The single most important benefit of employing earned value is the cost efficiency readings it provides…”.

Tools of Agile

In the Scrum world, what metric is there gives us a similar reading?  Shockingly, none.  Put aside SaFE and LESS for the moment, and just focus on a single project with perhaps one or two teams.

We know what our burndowns (or burnups) look like, but do they tell us what the value is?  Nope.  They are merely a metric of how much work has been performed, but with no real value assigned.  And here is where the conflict arises.  Scrum does not do a good job of providing people outside of the teams a way to understand what has been done, what has been accomplished, and how much it is worth.  Yes, stakeholders should be attending the reviews, and that is beneficial for everyone. But it does nothing to assign a metric to the value of the work performed the non-technical stakeholders can understand.


Bringing it all together again, in the end, we, the Scrum/Agile community, need some metric stakeholders understand and can be used to show growing value in exchange for the cost of the project.  EV is your ticket.

Using the same example as before, but let’s apply it in a more Scrum way.

I am going to make cars.  Each completed car is worth 5 business value points (BVP).  Starting in January, I am going to complete 1 car per month.  It is now March, I have only completed 5 BVPs.

Again, we see the same rate and numbers, except instead of dollars (or man hours) we are using Business Value Points.  A lot of Product Owners ignore this great tool, but it can be a valuable metric to decide ROI, and priority of the backlog items.  The power of BVP and their use is a topic for another time.

How does this help?  A product owner, along with other stakeholders will usually, at this point, figure out a dollar amount range to apply to each BVP, which in turn they will usually apply to story points.

Is this Agile?

It is not explicitly laid out in any Agile doctrine, but it is not forbidden either.  Like a team giving a reward to a member that stood out, or using a talking ball during standups.  While these practices are not laid out in an Agile methodology or framework, neither are they forbidden.

“But you can’t apply money to story points”, you cry, outraged.  The relative and somewhat fluid nature of a story point, especially early on in a team’s development, is not compromised by adding a money value after the sprint.  The team will still estimate correctly, there is merely a value being assigned based on performance, and the value should adapt as the team continues to perform and adapt themselves.

The business side, the side holding the purse strings, need these kinds of metrics to understand how the money is being spent, or they will just assume a bunch of highly paid engineers are playing ping-pong for half the day and watching Netflix the rest of the time.


Remember, control the PBL, and you will control the ROI.  If the stakeholders have numbers that are being spent, see the reviews, and read summaries, then Earned Value makes perfect sense. It is a metric that can be calculated without sacrificing the strengths of Agile.  Remember, the intent in all of this is to get a great product to market quickly.  That can’t be done without funding, and funding is often hard to come by for any amount of time without proof of life.


  1. Earned Value Project Management, A Powerful Tool for Software Projects; http://www.stsc.hill.af.mil/crosstalk/1998/07/value.asp