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 / CPI_{cum} EAC = AC _{cum} + BAC - EV_{cum} 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 - EV_{cum}) / CPI_{cum} ETC = EAC - AC _{cum} |

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 - EV TCPI (EAC) = (BAC - EV |

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

They are also presented as a graph.

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

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

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.

### 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 |

EV > AC | EV = AC | EV < AC |

SPI is Earned Value divided by Planned Value.

SPI > 1 | SPI = 1 | SPI < 1 |

Ahead of schedule | On schedule | Behind schedule |

EV > PV | EV = PV | EV < PV |

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.

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

### 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 = AC _{cum} + BAC – EV_{cum}** 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 - EV**_{cum}) / CPI_{cum}**ETC = EAC - AC**_{cum}

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 - EV**_{cum}) / (BAC - AC_{cum})

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

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

Thank you for taking an interest, Duy Hoang! The spreadsheet is currently unavailable. But you may find some useful tools on Chris Fortuin’s site (see the link in the article).

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 »

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.

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

Hello Iris. We have updated the spreadsheet image. Thank you for pointing out!

Thank you Mrs Yatskevich, I still think your TCPI (BAC) calculation for Sprints 2-13 are incorrect. I am getting for example Sprint 2 1.03, sprint 3 1.11, S4 1.25, S5 1.27, S6 1.39, S7 1.62, S8 2.78, S9-30.00, S10 -2.15, S11 -0.62, S12 -0.14, and S13 0.09 for sprint 13.

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!

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.

Dear Iris, thank you very much for scrutinizing the spreadsheet! I have revisited the article and fixed the errors.

Thank you for the prompt response.