There are many advocates in the world that state Earned Value Management (EVM) is the absolute way to know whether you are going to have success in a project, IT or otherwise. The Agile community has adopted velocity and its cumulative effect in either release burn-up or burn-down charts as the means of knowing what scope you can deliver by a certain date. In response to this, there are MANY people that have developed Agile EVM techniques; a simple Google search will reveal several papers or posts on this topic. If you don’t believe me, just click on this simple link querying Agile EVM.
I’m not going to say any of these are wrong. I will say that most, if not all, of these approaches add an amount of unnecessary complexity. Before I go further, there are two relevant, important Agile Manifesto principles I want to key in on…
“Working software is the primary measure of progress.”
Whatever progress metric we use should key in on whether software is deemed working or not.
“Simplicity–the art of maximizing the amount of work not done–is essential.”
Whatever approach we take should be as simple as it is practical; spending extra work on something that is not producing working software (the goal for software development activities), should be minimized. Note, I did not say eliminated.
So I don’t advocate the approaches that the Google search results in. Let’s start with some possible assumptions for why you might be needing EVM reporting so that you can frame whether EVM is actually required.
Assumption 1: You have some form of policy that requires reporting progress using EVM.
This is often found in the Federal Government; policies for large programs often require progress measurement using this technique. Unfortunately, the government does a horrible job in differentiating techniques between different types of development work except in name only; Major Automated Information Systems are treated in many ways as Major Military Construction as Long-term Pollution Reclamation in terms of progress measurement. Large corporations don’t fare much better and often codify the technique in policy.
Assumption 2: You need to adapt progress reporting to what middle management and executives understand.
Most executives understand milestone completion. They may falsely assume that milestone completion equals business value. In ideal EVM cases, it does, but in most development, particularly software-centric development cases, it does not. It equates to the end of a phase gate. For a discussion on value production in this model see my prior post: “Changing Your Viewpoint of the Project Management ‘Iron’ Triangle (Part 1)”. Here you can look at milestones as checkpoints on some percentage towards value.
Assumption 3: You honestly need to know if you will have a set of features done by particular dates and those dates are important for some reason (i.e. they were not arbitrarily set). Furthermore, these feature sets are unlikely to drastically change in terms of scope or priority.
While other approaches can give you this answer, EVM is the approach with which most people are familiar.
If none of these assumptions are true, I’d suggest you look to other measurements for progress, such as running tested features. Also, be mindful, that singular measurements reap teams to behave in certain ways and this may not what you want. That is the subject for another post, though.
So these assumptions are true; this seems to point to using EVM. Now what? First, remember we want to produce working software based on business value as articulated by the business. To understand this in more detail, see part 2: “Changing Your Viewpoint of the Project Management ‘Iron’ Triangle (Part 2)”. We don’t want to select any form of EVM reporting that gets in the way of this value production curve.
To do this, I’d suggest looking at your release (and perhaps your product backlog as well if you need a higher level view) and organize these work items (Epics, Features, Capabilities, Needs – whatever you use) into prioritized themes. Once you get down to your iterations (Sprints), the Epics themselves will organize the stories into more detailed ‘themes’. Let’s use Epics as our representation; please refer to the following diagram…
Each epic spans several iterations (in the example above there are three Epics). An Epic may be completed within an iteration and if the team is working in true priority order, they may begin on stories that are in a different Epic. I can align my milestones thus to the end of the iteration in which these Epics are completed; so far Epics that are completed within an iteration, the milestone still occurs at the end of the iteration. Want slack (management reserve) in the schedule? Move the milestone to the end of the iteration after it.
At the end of each iteration, we’re producing working software, so this aligns our milestones with iterations where working software is being produced. This approach also ditches all the mathematical approaches trying to have velocity convert to EVM, making it more simple. It also makes the change in mindset for executives and managers to one of just realigning milestones to working software and not phases. You are not asking them to fully change their mindset on schedules, just recast what they are based on. You can defer tackling how schedules such as this may not be the best at a later time. Once they get used to seeing working software, it will be easier to get into a mindset of value production over meeting schedule.
I would be remiss not to mention a possible issue with the above approach; for the first two assumptions, you run the risk that later milestones will no longer be relevant the longer the release cycle is that you are measuring; keep release cycles short so that the milestones remain relevant.
So what about velocity? Velocity is still appropriate for understanding release progress; it is just more for consumption by the team and is a better indicator for what a team may need to do in order improve and/or react to how their progress is going. EVM is more for reporting upward. It lacks the granularity for identifying symptoms that may need to be investigated. So it’s not so much an OR, but an AND; one for reporting outward progress when necessary and one for internal team improvement.