EVM provides a set of results that gives an objective insight into project performance. The Project Management Institute (PMI) has promoted it by including it as a standard in PMBOK guide.
EVM integrates technical performance, schedule, and actual cost to provide a metric for work completed. The single most important benefit of EVM is providing cost efficiency readings. These readings help provide the early warnings of performance problems while there is still time for corrective action.
What is AgileEVM?
Scrum framework has not provided any standard approach to measuring cost or performance. Here I am adapting a traditional EVM implication to Scrum framework in order to measure the performance.
AgileEVM is a term used by people that follow or bring EVM into the Agile world.
Related Article: EVM: Project Management With the Lights On!
The idea behind AgileEVM is to measure progress at the end of each sprint when actual velocity and actual costs are known. To measure AgileEVM, we need to have a minimum of 4 key values. They are:
- Actual cost of the project
- Estimated product backlogs
- A release plan, which provides information on the number of sprints
- Velocity, to know how many points can be done in each sprint. Velocity can be measured in Story points, units, days, and work hours, etc. We will examine some of the core concepts, which help measure performance. In general, we can measure performance after every Sprint or while in the middle of the Sprint.
Common EVM Terminology
Before diving into the calculations, we need to have a common understanding of EVM terminology.
Budget At Completion (BAC) = The budget assigned to complete the work
Planned Value (PV) = Expected % completed * BAC = Budgeted cost of work scheduled (BCWS)
Earned Value (EV) = Actual % completed * BAC = Budgeted cost of work performed (BCWP)
Actual Cost (AC) = Actual cost for the release (Cost * Total hours spent)
Cost Performance Index (CPI) = EV/AC
Schedule Performance Index (SPI) = EV/PV
Actual Percent Complete (ACP) = Story points completed/Total story points planned (Within the sprint calculation, we have to use points completed/points scheduled)
Expected Percent Complete (EPC) = Number of sprints completed/Total sprints planned
An Example of AgileEVM at Work
Let’s assume there is a need to develop a website, and let’ say after detailed discussions and brainstorming with the Product Owner and key stakeholders, we came up with the Product Backlog below.
Once you know the backlogs, you need to determine how many story points each backlog gets and estimate the number of sprints. For this exercise, I made an assumption that the total number of story points was 272. Remember, story points always need to be converted into the number of work hours. There is no hard and fast rule for estimating the number of story points or relating the story points with the number of work hours.
One of the important key points here is, as an estimator, we need to estimate how many story points can be completed in each iteration (sprint) based on the people assigned to the project. In other words, we need to estimate the velocity of how many story points can be completed in each sprint. For our exercise, I estimate the velocity of each sprint is 17.
One last thing we need to know is the cost per point. The cost per story point can be derived by identifying the number of work hours of each story point, multiplied by the hourly cost. To keep things simple, the hourly cost can be calculated from the average cost of all the team members’ hourly cost. For the sake of the exercise, I will use each point’s cost as $1,600.
Based on the data that we have, let’s calculate BAC and number of sprints:
BAC = Cost per point * Total story points = 272 * 1600 = $435,200
No. of sprints = Total story points / Estimated velocity of sprint = 272/17 = 16
Measure Sprint Progress
Let’s assume we are at the end of sprint 1 and we wanted to measure the performance. To make things interesting, though initially we estimated each sprint velocity as 17, we will assume the team completed only 7 points in sprint 1. The table below shows the performance measure values at sprint 1. The calculations are based on formulas provided in the ground rules.
By looking into the case study we can clearly say the project is behind schedule, as SPI is less than 1 (or EV < PV). Apart from burndown and velocity charts, we can also create EVM performance measure charts like PV vs EV, BAC vs EAC, etc. for readability, better understanding and for better reporting purposes.
Common Questions About AgileEVM
There are some common questions that generally arise when we implement EVM in Agile (Scrum). Let’s look at some.
Regarding re-baseline: One very important concept that we need to remember is that Agile-Scrum allows changes to the backlog at the end of each sprint (iteration). To get the changes accounted, we need to re-baseline after every sprint occurs. In general, we need to re-baseline after a scope change, but in the Agile-Scrum world, we need to consider re-baseline after every sprint.
The AgileEVM calculation helps validate the release plan with these modified backlogs. This validation helps us to know whether we will be able to complete the work within the given schedule and budget.
When we need to plan sprints and BAC: All the initial ground work related to estimating the budget, sprints and points will be estimated in sprint 0. We carry this information and use it in the AgileEVM calculation between sprints or whenever we need to know the project performance.
Can I measure performance whenever I want or do I only need to calculate after each sprint? AgileEVM can be measured at any point in time. This means it can be measured at the end of each sprint or while the sprint is in progress.
Is this is the only way we can measure AgileEVM? No, this is only one of the standard approaches. There are a couple of other ways people use this, like measuring the cost by the number of work hours rather than story point.
In the above example, in order to make things simple, I measured the cost with the story point. To get the actual cost, one needs to consider cost per hour. This process will become a lot easier if we use a standard Agile Project management tool. At the same time, it’s good to know the internals.
AgileEVM helps us to know the Project performance accurately. This information helps us make better decisions on release. Remember predicting failures early is a success.