This document proposes merging agile software development methods with earned value management (EVM) to leverage the benefits of both approaches. It describes EVM, which measures planned cost and schedule performance, and agile methods like extreme programming (XP), which emphasize adapting to changing requirements. The document suggests making EVM tasks smaller and measuring completion in an agile-like manner (0-100% complete). This could make EVM behave more like agile while maintaining EVM principles. It outlines how XP estimates work and discusses integrating XP and EVM to measure delivered value in a way that counts what matters without hindering project teams.

1. Submitted to Agile Development, June 25–28, 2003 Salt Lake City, Utah
Agile Project Management Methods Meet Earned
Value Management
Glen B. Alleman
Michael Henderson
Kaiser–Hill LLC
Golden, Colorado
glen.alleman@rfets.gov
michael.henderson@rfets.gov
Abstract: Earned Value Management Systems (EVMS) provide valuable in-
formation for planning and controlling complex software development projects
in high ceremony environments. The primary shortcoming of EVMS is its em-
phasis on retrospective data and the concept of driving in the rearview mirror.
Agile software development systems provide tools for adapting to changing re-
quirements in low ceremony environments. The primary shortcoming of Agile
development is it inability to participate in large population of government and
commercial development environments where staff and funding are managed in
more formal ways. Instead of requiring the high ceremony environment to
abandon their primary project reporting method, merging Agile development
activities with trusted earned value management reporting is an obvious ap-
proach. The principle management concern in every environment is how much
value is being delivered for the invested funds. The answer to this question is
the natural domain of the metrics of EVMS. Merging EVMS with Agile devel-
opment processes creates new synergies by leveraging the best of both proc-
esses in a variety of domains. This paper describes such an effort in a Depart-
ment of Energy IT environment.
1. INTRODUCTION
Measuring progress to plan on software projects is difficult but important no mat-
ter what the business domain. The Agile community claims such measurements are a
natural part of their development methods. Extreme Programming, SCRUM, DSDM,
FDD, Crystal, etc. provide techniques for capturing requirements, developing high
quality software, and delivering value to the customer. [1] The discussion of the effec-
tiveness of an Agile method in a specific business environment is not the topic of this
paper. Using Earned Value Analysis (EVA) to report progress to plan is assumed. The
question is how can Agile software development methods be integrated with EVA to
achieve the benefits of both approaches while also maintaining the integrity of both
approaches.

2. BACKGROUND
On government agency, construction, and civilian aerospace technology projects
the “earned value” performance measurement technique has been used since 1967.
The United States Department of Defense originally required earned value to be im-
plemented with Cost/Schedule Control Systems Criteria (C/SCSC). In the past, many
programs managed under C/SCSC assumed software development was unmeas-
uredable and classified this development as a level of effort. [2]
In the past C/SCSC was required on significant contracts and subcontracts within
DoD, DoE and other sub–agency acquisition programs. DoD instruction 5000.2 de-
fines significant contracts as research, development, test, and evaluation contracts
with an estimated cost of $60 million or more (in FY 90 constant dollars), or pro-
curement contracts of $250 million or more. This number seems ridiculously high for
the typical software development contract or project in any modern organization.
However the cost and schedule of a typical ERP system, enterprise level e–commerce
development, multi–site manufacturing execution system, or large–scale customer
relationship management system can easily approach $10 million and many years if
left unchecked.
EARNED VALUE MANAGEMENT OVERVIEW
The Earned Value Management principles define the methods to:
§ Plan all work scope for the program to completion
§ Break down the work scope into finite pieces that can be assigned to responsible
person or organization for control of technical, schedule, and cost objectives.
§ Integrate program work scope, schedule, and cost objectives into a performance
measurement baseline plan against which accomplishments many be measured.
Control changes to the baseline plan.
§ Use actual costs incurred and recorded in accomplishing the work performed.
§ Objectively assess accomplishments at the work performance level.
§ Analyze significant variances from the plan, forecast impacts, and prepare an
estimate at completion based on performance to date and work to be performed.
§ Use EVMS information in the company’s management processes.
Like any good methodology a set of terms unique to that method are needed.
Earned Value terms include:
§ Budget Cost for Work Scheduled (BCWS) – this is the Plan and represents the
total budgeted cost. It answers the question how much do we plan to spend?
§ Budget Cost for Work Performed (BCWP) – this is the Performance or Earned
Value and is the cost originally budgeted to accomplish the work that has been
completed. It answers the question how much work has actually been completed?
§ Actual Cost for Work Performed (ACWP) – this is the Cost of the Performance
or the Investment and is the actual cost to accomplish all the work that was per-

3. formed. It answers the question how much did we actually spend to deliver the
Earned Value?
2. THE VALUE CREATION PROBLEM
The critical aspect of Earned Value Analysis is the determination of “value” de-
livered (BCWP) in exchange for hours or dollars invested (ACWP) for software pro-
jects. This earned value is the basis for determining the cost and schedule perform-
ance for a task or project.
The “simple” way to calculate the earned value is to consider tasks as:
§ 100% complete when 100% of the budgeted funds have been expended. In this
case BCWP = BCWS. In this 0/100% approach, no credit will be given to the task
until it is 100% complete. At that time BCWP = BCWS, otherwise BCWP = 0.
§ 50% of the credit for BCWS is taken when the task starts and the remaining 50%
is taken when the task ends.
§ Discrete milestones within the task. The BCWS is assigned as earned value at the
completion of each milestone.
§ Percent complete within the task. This is a subjective assessment of the amount for
work performed for each work period. This value is then used to calculate BCWP
as a percentage of BCWS for the task.
EVMS VALUE MEASUREMENT
All of the methods described above depend either on a binary event or some sub-
jective assessment of the progress that has been made during the reporting period.
Both approaches fail the integrity test for software project management. This test asks
the question – how do we know that the software will behave as specified? If it does
behave as specified, then the development phase is complete. If not, then rework is
needed.
AGILE D EVELOPMENT VALUE MEASUREMENTS
If we take the approach of booking 0% or 100% of a task as BCWP AND make
the task durations sufficiently small, something happens to the EVMS “value generat-
ing” approach – it looks like an Agile software development process. With this fine–
grained task breakdown process, all the EVMS principles are still in place, but the
behavior of the management system has many of the attributed of an agile process.
There are still gaps to be closed, but the two paradigms are now closer together
than one would first imagine.

4. XP’s Approach to Measuring Delivered Value
In the Extreme Programming paradigm work is planned in small releases. “Sto-
ries” define the scope of work for the release cycle. These “stories” define what the
system will do. Programmers estimate the effort for the “stories” in units of “points.”
This process is called the “Planning Game.”
These “points” are dimensionless units that represent the relative complexity of
the “story” as well as the productivity of the development team. In the “Planning
Game” the developers create “Stories” in which they:
§ Get the customer to tell them “stories” about how the system will work
§ They write these stories down on cards
§ They organize the cards into topics
§ They classify the cards as High, medium, Low priority
§ They define an associated Functional Test foe each “story”
With all the programmers working as a team a “Release Plan” is created. This
process estimates to the resources needed for the iteration, the estimated “velocity” in
units of “engineering weeks.”
In XP there is a defined sequence to creating a “Release Plan:” [2, 3, 12]
§ Write enough stories to define a successful product
§ Do any necessary exploration
§ Estimate the difficulty of implementing each story
§ Estimate the speed of the story implementation in units of “points”
§ Choose stories for the first release based on the business value and difficulty of the
stories.
There are several interesting aspects to this approach:
§ The units of measure are arbitrary. “Points” have no normalized unit of measure.
<Find out specific units from XP teams>

5. MERGING EVMS WITH AGILITY AND MEASURING VALUE
3. EVMS AND AGILITY FRAMEWORK
4. INTEGRATION OF XP WITH EVMS
Not everything that can be counted counts, and not everything the counts can be counted.
– Albert Einstein
An earned value management system is not a reporting system, contract admini-
stration, cost analysis, accounting, or a contractor's task management system. It is a
measure of the value of physical progress in a project and as such adds additional
effort to the work of managing a project. Beyond the additional effort of an EVMS,
care must be taken to avoid hindering the project team’s ability to use its organic
management systems.
With the Earned Value and Agile methods now outlined, let’s look at the similari-
ties of each as ask why can’t Agile methods be used in an EVMS environment?
Earned Value Management Methods Agile Management Methods
Define the scope of work
Develop an integrated bottom–up for
performing the scope of work
Assign resources for each task in the plan
Measure the performance of these re-
sources against the plan
Measure the cost efficiency against the
cost plan
Forecast the final cost based on the cur-
rent performance
Manage the remaining work
Mange changes to the baseline

6. 5. REFERENCES
The following resources have been used as assemble the compendium of ideas pre-
sented in this paper. Since many of the ideas presented here are not mine, I give full
acknowledgement to the original source and authors of the materials presented here.
1. Abrahamsson, Pekka, Outi Salo, Jussi Ronkainen, and Juhani Warsta “Agile
Software Development Methods: Review and Analysis,”, ESPOO 2002.
2. Beck, Kent and Martin Flower, Planning Extreme Programming, Addison
Wesley, 2001.
3. Beck, Kent, Extreme Programming Explained, Addison Wesley, 2000.
4. Christian, David S. and Daniel V. Ferns “Using Earned Value for Performance
Measurement on Software Development Projects,”, Acquisition Review Quar-
terly, Spring 1995, pp. 155– 171.
5. EIA Standard 748–A: Earned Value Management, January 2002.
6. Fleming, Quentin and Joel Koppelman “Earned Value Project Management a
Powerful Tool for Software Projects”
7. Fleming, Quentin, “Earned Value for the Masses,” The Measurable News, Dec
2001.
8. Lett, Steve, “Earned Value Management for Self Directed Software Teams,”
Software Engineering Process Group, Lockheed Martin.
9. Lipke, Walter H., “EVM and Software Project Management: Our Story,”
Crosstalk, November 2002.
10. Lipke, Walter H., “Software Project Planning, Statistics, and Earned Value,”
Crosstalk , December 2002.
11. Lipke, Walter H., “Applying Management Reserve to Software Project Man-
agement,” Crosstalk, March 1999.
12. Jeffries, Ron, Ann Anderson, and Chet Hendrickson Extreme Programming
Installed, , Addison Wesley, 2001.
13. Jeffries, Ron, “Extreme Programming,” ACM professional Development Semi-
nar, May 12th , 2001, Boulder County Chapter of the ACM.
14. Solomon, Paul J. “Using Earned Value to Manage Successful Software Projects”
15. Solomon, Paul “Practical Software Measurement, Performance-Based Earned
Value,” Crosstalk , September 2001.
16. Solomon, Paul, “Going from Performance Based Earned Value to CMMI,”
Crosstalk , September 2002
17. Using EVMS on COTS– Based Systems, CMU/SEI– 2002–TR– 022.
Glen B. Alleman is the Director, Program Management Office of Kaiser–Hill LLC. Prior to KH,
Glen was a member of a small consulting firm specializing in ERP systems architecture and
deployment.
Michael Henderson is the Manager, Applications Development of Kaiser–Hill LLC. Prior to KH
Michael was a Vice President of Development with Computer Associates.
Kaiser–Hill LLC is the prime contractor for the Rocky Flats Environmental Technology Site,
Golden Colorado. Michael and Glen work in the Information Technology Department of KH–

7. LLC, providing applications and infrastructure support of the closure of Rocky Flats on or be-
fore December 15th, 2006.