Can Earned Value and Velocity Coexist on Reports?

Software developers are increasingly certain that a more agile, flexible approach to creating software is the best way to produce high-quality, working features that solve customer problems and provide business value. However, project management offices (PMOs) are continuing to develop procedures and train project managers on more traditional approaches that work successfully in many non-information technology areas of the corporation.

Is there a way to blend the reporting between the two factions, so that upper management can have matching metrics from both areas? Yes. Sort of.

If you are new to earned value, it is a numeric tracking of progress and the business value of that progress on a weekly, monthly, or quarterly basis. In an over-simplistic explanation, ignoring the cost factors, the project manager (and other stakeholders) define requirements and estimate the amount of time it will take to do the work of the project. These estimates are converted into a schedule.

Let's say the reporting time period was one week and the project team estimated it could do 40 predefined tasks in that week. Friday afternoon, the team reports its actual progress. If it got all the tasks finished in those 40 hours, it "earned” 40 hours worth of value (EV). It had estimated, or planned, 40 hours' worth of value (PV). EV-PV=SV, or schedule variance. In this case, the team had zero schedule variance.

However, if the team got behind, the schedule would be behind and other workers down the line would need to be alerted. If the team finished early, the original estimates might be excessive, and incoming materials or other project participants would need to know that their tasks may start earlier than anticipated. Remember, the scope (work) of the project has already been set.

The agile term velocity means measuring the productivity of a developer. It is used to allow that person to undertake an estimated amount of work for an upcoming week, not to exceed the amount of work s/he completed last week. However, since this developer is only being compared to himself and his last week's choices, rather than a long-term schedule, there is no need to reschedule the work of others. Further, the tasks for this week may be easier, have fewer bugs, or be more familiar to the programmer.

In the software development project, the functionality of the end product has not been set in stone. So if the velocity isn't as fast as originally estimated, the scope (amount of features delivered) can shrink.

The software project manager who is rolling reports from the software development project in with marketing, manufacturing, and training issues needs a reporting metric. The simplest approach is to give information technology a block of time (and a corresponding payroll amount) to work on the software. On the reports, show five weeks of time, for example. When your IT team submits weekly software reports, have it also submit the features/stories completed for you to convert to task names and enter into the report after the fact. Now those tasks can be updated to show that they are 100% complete as planned. This allows traditional reports to show agile progress.