A Better S Curve and Simplified EVM
June 06, 2008
“S Curves” are great to track project spend. They are simple to interpret and quickly let us see if we are over or under budget.
However, we could be doing fine spend wise, but behind from a schedule perspective. This is where Tracking Gantt charts come in and show schedule.
Yet, Gantt charts lack the spend component. Pretty soon most projects get ahead or behind in spend and time and so trying to gauge the overall project health becomes difficult.
This is why Earned Value Analysis (EVA) and Earned Value Management (EVM) were created, combining both spend and progress variables to produce a comprehensive set of project measures and metrics. However, there begins the problem.
What’s Bad about Earned Value
EVA is beyond most project stakeholders -
Most people who are not using EVM every week do not understand the terms. “Is a negative Schedule Variance good or bad?”, “What’s the difference between BCWP and EV?” (Answers: it is bad, and they are the same). Despite its usefulness, the confusing terms and heavy use of math puts off a large percentage of the population.
Debates digress beyond numerical accuracy - More challenging still is when several people do understand EVM and start debating which versions of the formulae to use and everyone starts obsessing on the math instead of the project. “Should we use EAC = BAC/CPI, or EAC = AC + ETC, or EAC = AC + [(BAC-EV)/CPI ?” Geez people, the developers probably pulled half of these estimates out of the air and we are applying advanced math to them?
What’s the value in tracking progress against a flawed plan? - EVM compares actual project performance to planned performance at a point in time. So, if our initial plan is wrong we could be effectively trying to do the equivalent of tracking our progress on a road trip from Calgary to Salt Lake City on a map of France! The quality of the baseline plan is a critical success factor of EVM. In agile projects we acknowledge initial plans will likely need changing and so the basis for effective EVM is quickly eroded with evolving plans.
Where’s the Quality? - We could be on time and on budget, but building a horrible product that the business does not like or is low in quality. We should be aware that cost and schedule are not the whole picture. EVM and agile alternatives are just a part of the picture.
What’s Good about Earned value
It is a Leading Indicator - Perfect rear vision is not of much use to people. At least EVM tries to predict completion dates and final costs. Imperfect leading metrics are always more valuable than perfect trailing metrics, since they give us options to re-plan and change our approach.
It is visual - It is easy to forget the EVM graphs and focus on the numbers, but at the heart of the process are some useful graphs. Visual is good because it engages the right-side of the brain and helps us draw on more mental power to understand, interpret and plan appropriate responses. Visual things are also better to discuss and collaborate on since we can point, annotate and extrapolate easier than with words or numbers.
Agile Alternatives
So how can we maintain the Leading and visual components of EVM and reduce some of the down sides? Well "Double S Curves" are a good start.
In this graph we have a familiar spend line shown in green tracking to the dollar scale on the right hand axis; and also a feature based line shown in blue tracking against the points scale on the left.
The gradient of the blue line indicates project velocity. Where it rises steeply we got a lot of points developed in a short time, where it is flat, progress was slow.
Adding a background on the graph can be useful to show functional areas. Here we can see that the “Configuration” and “Stock” components of the system have been built and we are currently in the “Sales” piece of functionality at just over 1000 points worth of functionality completed.
Also, at the end of 2007 the step in the background image shows where the scope of the “Sales” portion of the system was increased, shifting the remaining functional areas out by the new work amount. Yet we are still missing projections and a sense of if we are ahead or behind from both spend and schedule perspectives. This is where predicted values come in.
Now we can see how we are comparing against our projections. In this example we are overspent and a little ahead of progress currently, but the trends in velocity do not correlate with the continuing velocity improvements predicted.
As a replacement for Earned Value Management, these graphs are all you need. We can get the same metrics and indices right here.
Traditional EVM metrics like Schedule Performance Index (SPI) and Cost Performance Index (CPI) can be easily translated into Agile terms. For example, if we planned to complete 30 stories this iteration, but only completed 25 then our SPI is 25/30 or 0.83 (we are working at only 83% of the rate planned). Likewise, CPI is the Earned Value (Completed Features Value) to date divided by the Actual Costs to date, in the example above $2.2M / $2.8M = 0.79. This means we are only getting 79 cents on the dollar compared to what we had predicted, (but of course, who is to say what we predicted is correct.)
Cruel Irony
I find it ironic and amusing that “Earned Value” is a traditional project management term and agile projects often track progress in nebulous “Points”. This is backwards. Agile projects deliberately relate things back to real business value, and yet many traditional project track progress against tasks that add little or no business value and call the process “Earned Value”.
Creating a detailed requirements document that formalizes an incomplete, premature view of requirements that should change as details emerge and business continues to evolve is not earning much value at all. Yet prioritizing features by business value and tracking progress against the business oriented features is an excellent example of real “Earned Value”.
Next Steps
I have uploaded the example spreadsheet used to produce these graphs so you can get started with your own if you are intersted. The Excel “tricks” are as follows:
1) To get the two graphs on the same chart use the ‘Line – Column on 2 axes” graph option. This is on the “Custom Graphs” tab in old versions of Excel, In the Vista version of Excel, add a secondary axis to a normal line graph, by Formatting the data series, then click “Secondary Axis” on the Series Options tab.
2) Create a background image with bands that vary in height corresponding to their points estimates. E.G. a project with two phases one 300 points and one 200 points, would have background image with two bands, one, say, 3cm high the other 2 cm high. Just as long as the proportions are correct the image will be scaled to fit the graph region appropriately. I simply use PowerPoint to create my background images, but you can be as fancy as you like.
3) In Excel format the axes and adjust the Min. and Max values from 0 to you budget amount and points estimate for the project. If these number change, create a new background image and reset the scales.
Tool support
I try to keep up with the agile PM tools, but as far as I know, Rally, VersionOne, Target Process, Mingle, XPlanner, etc do not produce these graphs yet. I hope they do soon and calculate the EVM numbers too. I talk to many organizations who want to apply EVM type analysis on agile projects or work with PMO’s that ask for these stats.
Discussion on when it is appropriate to use straight line extrapolation to calculate Estimates At Completion (EAC) and the impacts of updating plans will be the subject of a future post. In the mean time you can also read a research paper on the topic written for the 2006 Agile Conference.
Download rp2_cabri_griffiths_agile_and_earned_value_reporting.pdf
Very good post. I liked the line 'We could be on time and on budget, but building a horrible product that the business does not like or is low in quality.'
Keep the good quality of your posts up.
Posted by: virk | June 11, 2008 at 09:50 AM
When you comment that "Traditional EVM metrics can be easily translated into Agile terms" you say that CPI is the 'Planned Costs to date' divided by the 'Actual Costs to date'.
That is not true. Performance Indicators in Earned Value always use EV as a reference.
CPI is EV (Earned Value) divided by AC (Actual Cost to date)
From your examle:
EV is the value of 25 stories (About 2.2M from your example)
AC is Actual cost to date = 2.8M
So
CPI = 2.2M / 2.8M = 0.78
Posted by: Romildo Votto | June 25, 2008 at 04:09 AM
Hi Romildo,
Thanks, you are correct, CPI is, and always will be EV/AC. I have fixed up the slide and sentance. Many thanks for pointing this out.
Regards
Mike
Posted by: Mike Griffiths | June 25, 2008 at 07:11 AM
Great post Mike. You tell it like it is.
Posted by: Jonathan Rasmusson | July 07, 2008 at 10:32 AM
Great post Mike. You tell it like it is.
Posted by: Jonathan Rasmusson | July 07, 2008 at 10:32 AM
Hi Mike,
Great post, thank you. I have a question with respect to how you generate the values for the 's-curve' in the example spreadsheet.
That is, I would like to generate a baseline s-curve automatically in Excel using just the estimated start date, end date and project budget.
Is there somewhere I can find this formula?
Thanks
Goran
Posted by: Goran | November 16, 2008 at 11:52 PM
Hi Goran,
I do not have formula for the underlying S curve.
As you can imagine, the gentle start of the spend S Curve comes from the reduced team size at the beginning of the project when you would likely only have a PM, a BA, and an architect on the project before ramping up the full project team. Likewise towards the end of the project you will normally be cutting down the team size as tasks finish up.
For an example of how this curve may be generated, see my post A Burn-Rate Based Estimation Tool that has an example.
http://leadinganswers.typepad.com/leading_answers/2007/04/a_burnrate_base.html
Given this data I guess you could find an equation for a line that follows this curve, but I start my estimates with this Burn-Rate spreadsheet and so have not had the need to find one.
I hope this helps, at least a little.
Best regards
Mike
Posted by: Mike Griffiths | November 18, 2008 at 02:32 PM
Very nice! I have also done some work in this space, and have reached similar conclusions. I've posted some details here -- http://www.agilekiwi.com/agile_charts.htm -- and am currently hoping to share some of these ideas with the traditional EVM community.
Posted by: John Rusk | March 30, 2009 at 11:55 PM
Hi John,
Thanks for the link, I agree with your thoughts and wish you well with your plans to share with the EVM community. Please keep in touch and let me know how it goes.
Best regards
Mike
Posted by: Mike Griffiths | March 31, 2009 at 07:04 AM