Earned Value Management (EVM) for Agile Software Projects

11 minutes

Agile software projects deliver business value by embracing change. Whatever business gains, this puts extra responsibility on project management:

  • How to control resources in forever evolving conditions?
  • How to ensure clarity and precision of cost calculations?

On the other hand, every stakeholder wants to know:

  • How well is the project doing?
  • Will it be on time/within budget?
  • How much more money/time will it take to complete this amount of work?
  • Do we need to take longer and accomplish all the features or cut short and make do with bare necessities?

Uncertainty about using Agile is still strong since Scrum framework seems to be missing the guidelines on cost and schedule control.

Performance metrics in Scrum projects

In fact, Agile employs a number of quantitative metrics for various parameters:

  • Story/feature/epic count – tracks functionality on a release level and beyond;
  • Story points – estimate overall size and effort for a release;
  • Velocity – a measure of sprint-sized working functionality and overall progress pace;
  • Sprint burndown – a daily estimate of work remaining in a sprint;
  • Release burnup – a comparison of actual effort against planned for a release.

However, businesses don’t find these metrics transparent and informative enough in terms of cost efficiency control. Agile EVM includes this missing cost component as an Earned Value metric.

What does Agile EVM do better than a release burnup chart

Agile EVM is more informative

Agile EVM provides the data of cost, performance and schedule allowing to:

  • Compare monetary expressions of value planned, earned and consumed at any given moment
  • Calculate cost and schedule efficiency
  • Make forecasts for the end-of-the-project time and cost

Agile EVM embraces change

It also deals efficiently with changes in plans. The most unhealthy practice in software projects is to allow informal changes to the technical baseline without changing the cost of schedule baselines–a practice commonly known as scope creep. In Agile EVM, scope change is reflected in a variable known as Scope Floor. Cost and time-related metrics register this change and other planning variables are adjusted to meet new conditions.

Agile EVM ties together abstract and time-bound valuations of effort

Another reason why Agile EVM is more informative is that it allows to tie in Scrum’s abstract valuations of size and complexity (user stories and story points) with more realistic metrics of time and cost. As Jeff Shurts puts it, ‘You’ll read over and over again in the literature that a story point is not(!) a representation of time, or of effort – merely one of scope or complexity. It bears relation to effort only through another agile measure – velocity’. The rationale behind abstract valuations is simple: Agile shifts the focus from deadly deadlines towards generating business value.

Where does Agile EVM derive from

Earned Value Management is not a product of Agile environment. It has been around since the 1960’s, a recognized project management technique, the subject of in-depth study by the Project Management Institute’s (PMI) College of Performance Management and now included as a standard in the “Guide to the Project Management Body of Knowledge”. Lately it has also become a successful practice in Scrum, introduced via Agile framework by Tamara Sulaiman, Brent Barton, and Thomas Blackburn in 2006.

Agile EVM: key concepts, formulae, and output

Here are the concepts of Agile EVM and their mathematical representation.

Short Concept Definition Formula
EPC Expected Percent Complete The amount of value planned to be delivered over the period in question Current sprint / Total planned sprints (PS)
APC Actual Percent Complete The amount of value actually delivered over the period in question Story points completed / Total planned story points (PRP)
PV Planned Value The budgeted cost for the work scheduled to be completed up to a given point in time. Formerly known as BCWS (Budgeted Cost for Work Scheduled) EPC * BAC
EV Earned Value The budgeted amount for the work actually completed during a given time period. Formerly known as BCWP (Budgeted Cost for Work Performed) APC * BAC
AC Actual Cost Corresponds to budgeted costs in PV for release. Formerly known as ACWP (Actual Cost for Work Performed). (actual sum added manually)
BAC Budget at Complete The initial budget for the release – coincides with PV for the entire project (agreed upon at the inception)
SV Schedule Variance The (monetary) difference between the planned and actual time to complete a certain workload EV - PV
CV Cost Variance The (monetary) difference of value incurred and cost to produce a certain piece of work over a certain amount of time EV - AC
SPI Schedule Performance Index An efficiency indicator for measuring the rate at which the project’s throughput is meeting initial schedule expectations. EV / PV
CPI Cost Performance Index An efficiency indicator for measuring the value produced for each $1 of actual cost. EV / AC
EAC Estimate at Complete Expected total cost of the project at its end EAC = BAC / CPIcum
EAC = ACcum + BAC - EVcum
EAC = AC + ((BAC - EV) / CPI)
ETC Estimate to Complete Expected additional cost needed to complete the project or from the point of calculation ETC = (BAC - EVcum) / CPIcum
ETC = EAC - ACcum
VAC Variance at Complete The difference between a planned and actual project’s cost VAC = BAC - EAC
TCPI To-Complete Performance Index Projected efficiency index

TCPI (BAС) = (BAC - EVcum) / (BAC - ACcum)

TCPI (EAC) = (BAC - EVcum) / (EAC - ACcum)*

They are visualised in a spreadsheet with both automated and manual input fields.

Agile EVM spreadsheet sample

They are also presented as a graph.

Agile EVM Release burndown chart

Release burndown chart for Agile EVM with scope increase (Courtesy of Chris Fortuin)

Step-by-step Agile EVM implementation via spreadsheet

A spreadsheet – is a perfect format for Earned Value Management. It automates basic calculations but allows for control and adjustment, thus providing simple and clear Agile EVM implementation.

Project-planning stage

Planning any project involves estimating scope, time, and cost – that’s the project manager triangle. The planning stage provides the necessary input data to use as a baseline for EVM calculations. Of course, we can only use historic data and intuition so far.

We are particularly interested in planning on the release and sprint levels.

What metrics to use as input data

When planning for a release, we estimate the scope in ‘planned release points’ (PRP), time – in ‘planned sprints’ (PS), and cost – in ‘budget at complete’ (BAC).

Agile EVM baseline per release

For a sprint, the currency for scope is ‘story points’ (SP), for cost – ‘planned value’ (PV), and time metrics include ‘starting date’ (SD) and ‘length’ (L).

Agile EVM baseline per sprint

All in all, following Sprint Zero, we have such input data:

Short Metric Definition
PS Planned Sprints Total number of planned sprints
BAC Budget at Complete Budget planned for the release
L Length Sprint length (in calendar days)
SD Start Date Start date of the project
PRP Planned Release Points The number of story points planned for the release, i.e. the total scope (in points)

Deriving project data

After each sprints, we collect the actual data. We have the metrics for:

  • The number of sprints completed
  • The number of story points done
  • the actual cost (AC)

With these values, we can calculate and compare:

  • the percent of scope done (APC, actual percent complete) against planned (EPC, expected percent complete)
  • the monetized value earned (EV, earned value) over ‘burned’ (AC, actual cost)

The time variable (number of sprints completed) is expressed via concepts ‘per iteration’ (it) and ‘cumulative’ (cum) in our calculations.

Deriving these metrics helps:

  • compare guesses for cost, time, and scope with facts;
  • determine efficiency (of planning and performing);
  • rebaseline the project estimates for more accurate forecasts.

Deriving project data for Agile EVM

Measuring project performance

Now we can see how well we are doing. The Cost Performance Index (CPI) and Schedule Performance Index (SPI) give a measure of efficiency. They show how efficiently you are actually spending your budgeted costs and time as compared to how efficiently you have planned to spend them.

For CPI, divide Earned Value by Actual Cost.

CPI > 1 CPI = 1 CPI < 1
Under Budget On Budget Over Budget

SPI is Earned Value divided by Planned Value.

SPI > 1 SPI = 1 SPI < 1
Ahead of schedule On schedule Behind schedule

Another way to measure efficiency is by calculating schedule and cost variance: SV = EV - PV; CV = EV - AC. Positive variance is good while negative means trouble: your project is costing you more than you’ve planned or earned so far. This can indicate one of these: either your estimates are bad, or you’re moving too slow. In any case, if you continue at this pace, you’ll probably have to reschedule the release date or cut functionality. Readjust your plan and keep stakeholders informed.

Measuring project performance in Agile EVM

Dealing with scope change

Change is inevitable in Agile projects. It may come from within (greater size of stories is revealed over time, which means more story points; velocity change; team size change) or without (more/less functionality is needed than originally planned; re-prioritization takes place). Agile EVM optimises the value of iterations when the new input data automatically become a new baseline for performance calculations.

When dealing with scope change, Agile EVM differentiates between the concepts of ‘change’ and ‘adjustment’. ‘Changes’ happen accidentally, without intention, whereas ‘adjustments’ are done on purpose by the PO for precision and efficiency.

Here are some cases of ‘changes’:

  • velocity fluctuates because defects are found during development or features are not accepted during Sprint Review or for many other reasons;
  • scope may change after feedback for Sprint review or when defects are found in production.

There is no need for adjustment here.

When do we ‘adjust’ the scope or velocity variables?

  • if PO adds a new feature to Product Backlog;
  • when a developer is leaving the team (but do not re-adjust the velocity if a new developer is added).

In Agile EVM, scope change is reflected in a variable known as Scope Floor (SF). This is actually scope ‘adjustment’ due to adding new SP or removing planned SP undone.

Agile EVM: Dealing with Scope Change

Making forecasts about cost and schedule

You can’t find a better predictor of near-term future performance than near-term past performance. Since every sprint is a new baseline, instead of using the INITIAL estimate in total number of Story Points, Agile EVM calculations always use the LATEST estimate in total number of Story Points to calculate CPI, SPI, EAC, etc. – to achieve greater precision of predictions.

What sort of forecasts can we make?

First of all, we predict what total cost to expect at the end of the project based on the changes to the project’s scope and schedule: Estimate at Completion (EAC) is best calculated using the formula EAC = ACcum + BAC – EVcum that embraces changing conditions.

Next, Estimate to Complete (ETC) gives us a forecast for the costs to be injected from the current date to the end. Either of these formulae can do the job:

  • (BAC - EVcum) / CPIcum
  • ETC = EAC - ACcum

We can also derive information about cost discrepancy between the planned and would-be consumed budget long before the project’s finishing line. Here’s how to derive Variance at Complete (VAC):

  • VAC = BAC - EAC

Finally, we can predict the project’s projected efficiency based on our current metrics. Here’s the formula for the To-Complete Performance Index:

  • TCPI = (BAC - EVcum) / (BAC - ACcum)

Forecasts allow us to make informed decisions about the best option of when, at what cost, and with what feature set to go to release.

To conclude

Successful implementation of Agile EVM depends on timely data input and accurate estimation. But the benefits are worth the effort.

The possibility of visualization as well as bringing time-bound and abstract estimates closer together makes Agile EVM metrics a perfect communication tool with businesses.

The technique for cost and time control adds value to Agile development over the traditional, waterfall, model and as such makes this methodology more reliable to those who would otherwise shy away from Agile.


  1. Tamara Sulaiman. AgileEVM: Measuring Cost Efficiency Across the Product Lifecycle.
  2. Tamara Sulaiman, Brent Barton, Thomas Blackburn. Agile EVM: Earned Value Analysis in Scrum Projects.
  3. Tamara Sulaiman, Hubert Smits. Measuring Integrated Progress on Agile Software Development Projects.
Did you enjoy the read? Was it useful? Your sentiment helps us to create better content. Use the reactions to assess the article. Or leave us a note in the comments. We are out here to boost your tech savvy.
4.5/ 5.0 rating (108 votes)
Leave a Reply
newest oldest most voted
Duy Hoang

Very helpful post. May I have the spreadsheet mentioned in the post?

Angel Todorov

Thanks for the exhaustive explanation of such an important topic as Agile EVM. I have a question though – I was able to replicate your entire spreadsheet, but the last index – TCPI. I am not sure how you ended up with TCPI values for sprints 2 – 13 (for sprint 1 I have the same value as you). To be more specific, let’s have a loot at sprint 2 calculations. We have: BAC = $4000, EVcum = $800, ACcum = $880, hence: TCPI = (BAC-EVcum) / (BAC-ACcum) = (4000-800)/(4000-880) = 1.03, however in your table it is 0.9. Let… Read more »

Konstantin Pogrebnoy

Hello Angel, thank you for your comment. Actually, there are 2 (two) To Complete Performance Indexes: TCPI (BAC) = (BAC-EVcum) / (BAC-ACcum) and TCPI (EAC) = (BAC-EVcum) / (EAC-ACcum). It seems we provided the formula for TCPI (BAC) but TCPI (EAC) was calculated in the spreadsheet. TCPI(EAC) = (BAC-EVcum) / (EAC -ACcum) = (4000-800)/(4400 -880) = 0.9090. Sorry for the confusion. I’ll ask Olga to update her article. Thanks for finding this mistake.

Iris Burrell (US)

The article and TCPI values still appear to be wrong after 1 year.

Angel Todorov

Hey Konstantin and thanks for the replay. If this is the case, then the calculation for the sprint 1, 3, 4 and etc isn’t correct since for sprint 1 it is TCPI(EAC) = (4000-400)/(4400-440) = 0.9090 and for the other sprints, the values also differ. Anyway – I will wait and see the updated spreadsheet. Thanks one more time!

Iris Burrell (US)

In the spreadsheet, the Expected Percent Complete(EPC) does not appear to be calculated based on the formula in the table: Current sprint / Total planned sprints (PS). There are 13 total planned sprints in the spreadsheet after Sprint 1 the EPC based on the formula should be 1/13=8%. How did the author calculate 10%? and why for the last sprint, the calculation is 153% as the expected % complete? The numbers do not seem to make sense to me. Please advise.

Gabriel Merlin Andrade

Very useful article. I’d like to better understand the difference between Actual Story Points (4th line of the table) and Story Points planned (cum) (12th line). Aren’t they both the total number of planned story points up to a certain sprint? Thanks.