Can Earned Value and Velocity Co-Exist on Reports?

From Project Manager 97Things

Jump to: navigation, search

Can Earned Value and Velocity Co-Exist On Reports?

Barbee Davis, M.A., PHR, PMP Omaha, Nebraska, USA

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 they could do 40 pre-defined tasks in that week. Friday afternoon, the team reports their actual progress. If they got all the tasks finished in those 40 hours, they “earned” 40 hours worth of value (EV). They had estimated, or planned 40 hours (PV) worth of value. EV-PV=SV, or Schedule Variance. In this case they had zero schedule variance.

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

The agile term, velocity, also measures 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 he/she 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 (IT) 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 you submit weekly software reports, also submit the features/stories completed (converted to task names) for the project manager to fill in after the fact. This allows traditional reports to show agile progress.

Personal tools