Earned Value Management (EVM) for Agile Software Projects

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.

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:

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.

SPI is Earned Value divided by Planned Value.

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.

Resources

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.