To provide the “complete view” from an EVM perspective, you can update traditional agile progress-monitoring tools, such as a burn chart, to incorporate cost data, effectively allowing for the tracking of both schedule performance (the number of stories completed) and budget performance (labor hours) on the same chart. In this way, it is possible to derive the key elements of earned value for individual iterations and the project as a whole when the total stories and costs for all iterations are combined, as Figure 1 shows.
Figure 1. Modified Agile Burn Chart for EVM
Using this modified burn chart as an example, the elements of earned value can be derived as follows:
- The “planned value” (PV) is observable along the “planned costs” curve and represents the estimated effort for all “planned stories (planned effort)” multiplied by team member labor rates.
- The “actual cost (AC)” is observable along the “actual costs” curve, and can be tracked as each story is completed by multiplying the actual effort for all “completed stories” by team member labor rates.
- The “budgeted cost of work performed (or earned value)” is derived from the “completed stories” curve, where the number of “completed stories” is multiplied by the estimated cost, which is the estimated effort for planned stories multiplied by team member labor rates.
- The “schedule performance index (SPI)” is calculated as [completed stories / planned stories], where a SPI of <1 indicates that the project is performing behind schedule and you must either refine estimates or the project scope may require adjustment.
- Similarly, the “cost performance index (CPI)” is calculated as [planned costs / actual costs], where a CPI of <1 indicates a cost overrun and, again, a possible need for you to re-estimate or adjust the scope.
A benefit of the agile approach to EVM is that stories are modular and re-usable throughout a project lifecycle. Once the team validates time and effort estimates for a given story in an individual iteration, it is possible to directly refine the estimates throughout the remainder of the effort, wherever a similar story may appear. By effectively re-baselining the total schedule and cost estimates with each iteration, project managers can provide increasingly accurate predictions of project performance as work progresses.
Without a doubt, though, the greatest single benefit of agile EVM is the frequency by which you can granularly track project progress. The project team monitors story completion daily during team stand-up meetings, and burn charts can quickly show variances in both schedule and cost performance. Using this information, government managers (even those unable to attend daily project meetings) are able to rapidly identify potential problems, ask informed questions, and address emerging issues before they have a chance to impact the rest of the project.
Ensuring Program Discipline and Repeatability
One of the final obstacles facing agile projects in the government space is the perception (encountered most often among individuals with limited agile implementation experience, or who have experienced difficult government agile implementations in the past) that agile efforts lack the discipline and repeatability in execution offered by more traditional development methodologies. With their bias towards rapid, iterative delivery of project functionality, agile projects emphasize face-to-face communication and simple documentation (for example, tests serve to document requirements) over the more detailed constructs employed for traditional projects. This “lightweight, just-in-time” approach allows project teams to react quickly, but can lead to coordination difficulties for larger, geographically distributed project teams, as well as increased ramp-up times for stakeholder groups joining the project in mid-stream and – where compliance with traditional government lifecycle review gates is expected – the expenditure of significant effort on creation of compliance-focused project documents that are not directly aligned with actual project work and thus provide minimal actual value to the project effort.