Earned Value Analysis in Scrum



Use Earned Value Analysis to Quantitatively Measure Schedule Deviation in Scrum Projects
Burn down chart is a most important tool we use to represent work left over time in our Scrum toolbox. We use this diagram to measure the current progress and how healthy the project status is by looking at the trend; it also provides a good way for the team to know the deviation of the current team velocity vs. the historical velocity if we use the historical data to estimate.
Let’s take a look at the below sample burn down charts, I created some sample data so that we can easily find how those burn down charts illustrate the project status. Notice that all these projects are running in parallel and are having the same start date.

Project A, each sprint lasts 3 weeks, the historical team velocity is around 165 story points per sprint.
pic1.png

Project B, each sprint lasts 2 weeks, the historical team velocity is around 30 story points per sprint.
pic2.png

Project C, each sprint lasts 1 week, the historical team velocity is around 50 story points per sprint.
pic3.png

If you are the ScrumMaster role who is taking care of one of those projects specifically, the above burn down charts are already good enough. But what if you are a PMO manager, or a Project Portfolio Manager who is taking care of all these three projects at the same time? Are you feeling comfortable to say that at one single moment, which project is having less schedule deviation? You might realize the below problems if you have to put those diagrams all together trying to come up with a quantitative comparism:
  • The sprint duration varies, if I want to compare Project C Sprint 1 (1 week) with Project A Sprint 1 (3 weeks), I have to wait until we complete Project A Sprint 1. But at that moment Project A is in Sprint 3 already.
  • The team velocity varies. Team B completes around 30 story points in 2 weeks while Team C completes around 50 in 1 week. Which team is delivering more?
  • The comparism base standard varies. All the three projects are using different technologies to build different products, 1 story point in Project A definitely doesn’t equal to 1 story point in Project C, how can we say which project is having less schedule problem if both A and C has 20 points left un-finished?
In order to resolve these problems, very naturally , we would come to the solution of equalizing the both horizontal and vertical dimensions in the burn down charts, use ratio numbers (percentage) to replace the real values (story points and days), so that all the projects with different characteristics will generate similar “burn down charts” , and the value on these diagrams will become comparable – we can easily say a project having 5% schedule delay is performing better than a project having 20% schedule delay if we compare only from the schedule perspective.
When thinking about how to have a quantitative calculate method, I recalled the Earned Value Analysis technology in PMI. It uses a very simple formula to calculate the schedule deviation:

SPI (Schedule Performance Indicator) = EV (Earned Value) /PV (Planned Value)

As the numerator, EV (earned value) stands for the total number of the original estimation (planned Value) for those as of completed stories.

EV.png

Here actually the “PV (Completed)” could simply be translated to the “Original Estimation of those completed work”, and since when using story point to estimate we don’t usually do re-estimate, hence this value could be easily calculated by using a MS Excel formula – to add up the story points belong to those user stories marked as “Done”.
But the denominator, PV is kind of tricky because in Scrum we don’t plan for when to complete how much work. However, we can have our own definition to get the rough “Planned Value”, I would like to just simply use the below formula since ideally every day the Scrum team should be delivering some pieces of working software.

EV.png

According to the above definition, SPI is just a simply ratio number (percentage) representing as of the current moment, the work has been done over the work should had been done.
Let’s use Project A in the above sample as an instance, below is the metrics data we collected daily, and the SPI value calculated from the below formula.

pic4.png

Now we have a mathematics basis to calculate the SPI value for the different projects. If we put all the 3 project data together, and calculate the SPI on a weekly basis, we can get the below table:

pic5.png

If you’re a PMO manager or a Project Portfolio Manager I bet you’ll be very happy because based on these data you’ll be very easily to quantitatively compare the schedule deviation in different projects with different characteristics like below:

pic6.png

To me it's a useful tool using a single indicator to illustrate schedule deviation among different projects, see if that makes some sense to your business context.