Many commercial companies have no requirement to use Earned Value and may want to skip this section completely.

EVM was created when sequential, or waterfall project management approaches dominated. Lean-Agile provides a project/program management approach to propose solutions, execute projects, and produce products for our customers. Are the two compatible? Can Lean-Agile work when Earned Value is required?

A Brief Introduction to Earned Value Management

Contract work for the U.S. Government typically requires the use of Earned Value techniques.

If you’re not familiar with it, Earned Value Management (EVM) is a practice for program management that is used across the U.S. Department of Defense (DoD), the U.S. Federal government, and the commercial sector. Government and industry program managers use EVM as a program management tool to provide joint situational awareness of program status and to assess the cost, schedule, and technical performance of programs for proactive adjustment as needed.[1]

Earned Value is intended to increase the value to all stakeholders by using means for managing programs. The American National Standards Institute/Electronic Industries Alliance (ANSI/EIA) Standard EIA-748, Earned Value Management Systems, defines the requirements of an acceptable EVMS if you need more detail.

These guidelines consist of five categories: (1) organization; (2) planning, scheduling, and budgeting; (3) accounting considerations; (4) analysis and management reports; and (5) revisions and data maintenance.[2]

Recent Thinking Indicates Lean-Agile and EVM can Work Together

Recent activities related to U.S. Government contracting have focused on how to use Lean-Agile even when EVM is required.

In 2015, the Office of Performance Assessments and Root Cause Analyses (PARCA) [3] held an open meeting to discuss the nexus of Earned Value Management (EVM) and Agile development within a DoD environment.[4]

This meeting produced many insights that indicate quite a few organizations are successfully making Lean-Agile and EVM work together. The following is a list of some of the relevant insights:

  • Deliver timely, relevant solutions thru iterative and incremental delivery [5]

  • EVM is needed to drive efficiency [5]

    • Demonstrates efficiency and provides input to needed course corrections

  • Some needs require continuous changes and upgrades across the lifecycle [5]

  • EVM is needed to drive consistent-objective results [5]

    • Layers of incentives tend to drive overly optimistic promises of results [5]

  • Agile is a mainstream process used across commercial industries [5]

    • Highly collaborative with consistent results

  • Impact to Core DoD Processes [5]

    • Requirements: Move from a fixed set of requirements to evolving requirements and user’s role throughout.

    • Delivery: Move from the static waterfall model to the Agile model with user feedback driving priorities

    • Governance: Move from driven by milestones and breaches to more frequent review- delivery focused

    • Functional Areas: Move from rigor tied to documentation for single milestone to rigor tied to demonstrated risk and delivery of capabilities

  • Changed the oversight and governance by replacing “trip wire” oversight to more frequent, less formal involvement [5]

Example to Demonstrate Lean-Agile and EVM Aligning

We agree with the broader community that Lean-Agile projects can be planned and executed to align with EVM.

Planning in Lean-Agile is distributed rather than all up front. Agile projects plan and execute in accordance with EVM. Agile promotes a strong, continuous planning discipline with the right level of precision for each planning time-horizon under consideration. Product Planning establishes the initial product backlog and product roadmap and provides the details needed to complete the initial schedule baseline and establish the performance measurement baseline (PMB).[6] In the following table, planning precision increases from the top row to the bottom row.

Table 1. Agile Planning levels related to Agile EVMS [6]
Planning Level Planning Frequency Planning Time Horizon Planning Precision Planning Artifact

Product Planning

Project startup; updates throughout the project

Project Duration


Product Backlog; Product Roadmap

Release Planning

Each incremental release/rolling wave

Incremental Release

Features/ Stories

Release Plan

Iteration Planning

Each iteration


Stories/ Tasks

Iteration Backlog

Daily Planning




Updated Iteration Backlog

Some of these discussions meant 'system' to mean software applications, but we mean it as courseware for this book.

Sometimes a worked example helps to visualize what we mean. The following is an example [6] of planning with Agile and EVM.

Table 2. Sample Schedule for Agile Planning with Inchstones
EV Level Task Name Start Finish


WBS control account ABC

Tue 5/18/17

Wed 4/2/18


--WBS work package DEF

Tue 5/18/17

Fri 11/8/17


----WBS milestone GHI

Tue 5/18/17

Fri 7/19/17


----WBS milestone JKL

Tue 7/22/17

Fri 9/13/17


----WBS milestone MNO

Tue 9/16/17

Fri 11/8/17

With this schedule, the following inchstones are associated.

Table 3. Sample Inchstones List for Agile Planning with Inchstones [6]
Inchstone Weight Status Earned





User Story 1




User Story 2




User Story 3




User Story 4




User Story 5




User Story 6




User Story 7


not started


User Story 8




User Story 9


not started


When using Lean-Agile, handling inchstones correctly is important for EVM.

Supporting Data for Milestones (not subject to BCR) [6]
  • Stories are used as inchstones for earned value reporting to reinforce value of working [courseware] over completion of development tasks.

  • Inchstones are not IMS tasks and therefore do not require budget, scope or schedule assigned to them.

  • Story point weightings are used to calculate the earned value contribution of each completed story.

  • Total story points earned is used to calculate milestone percent complete used for earned value reporting.

  • Incomplete stories are planned for a subsequent iteration but remain with their parent IMS milestone.

  • If a started story implements scope outside the WP, you need to open a new WP.

  • Inchstones may be changed without a BCR as long as:

    • Added stories are related to the features that comprise the scope of the associated milestone.

    • Removed stories are not necessary to complete the scope of the associated milestone.

Management will still want to know where we’re at during the project, so a burndown or burnup chart can help show progress against the backlog.

Agile Execution: Release Burndown [6]
  • The Release Burndown shows the number of story points remaining at the end of each iteration.

  • The Release Burndown is a leading indicator of schedule performance.

  • In the example, Sample Schedule for Agile Planning with Inchstones, the percent complete for the GHI milestone = 31/39 = 79%

What Others Have Learned Merging Agile and EVM

Often we can learn from what others have learned. The following lists lessons organizations have mentioned when merging Agile and EVM. Our experiences have also validated the lessons of others.

Lessons Learned
  • Some programs are bid waterfall, yet executing Agile, meaning bids have not all caught up to Agile yet.

  • Cultural changes are often harder than technical changes.

  • The schedule should only go down to the level of Features (not to the story level).

  • Hybrid Scrum works, so tailor to your needs.

  • When delivery teams are one of many (scaled agile), it can be challenging to accurately reflect progress to “done” for a large portfolio.[7]

  • Agile EVM accurately informs both the Productivity and Predictability Performance Measure Categories.[7]

  • Baseline Cost Per Story Point and track every iteration, and performance thresholds should be based on acceptable variations.[7]

  • Organizations vary on when to credit user stories in EVM. The 0/100 EV technique works well. Other possible crediting of stories includes:

    • 0% at start

    • 80% at story completion

    • 20% at customer acceptance (accounts for changes needed)

As with other improvements, we can apply lessons learned and continue to get better at applying EVM and Agile together. The following quote indicates that getting work done faster by using Agile might be just what we need going forward.

"Our conventional programs seek a 99% solution in years. Missions require 75% solutions in months." [8]
— Robert Gates, United States Secretary of Defense, 2008

1. EVM description reproduced from the U.S. Goverment site As such it is not entitled to domestic copyright protection under U.S. law. See for more information about EVM if desired.
2. Reproduced from the U.S. Goverment site and developed by the U.S. Government Accountability Office (GAO). As such it is not entitled to domestic copyright protection under U.S. law.
3. PARCA is part of the U.S. Goverment. It is a Directorate of the Office of the Assistant Secretary of Defense for Acquisition, As such its works are not entitled to domestic copyright protection under U.S. law.
5. Don Johnson, Office of the Secretary of Defense, As an employee of the US Government in official duties, his statements are not entitled to domestic copyright protection under U.S. law.
8. Robert Gates, the United States Secretary of Defense, 2008, Agile Methods: Selected DoD Management and Acquisition Concerns, Carnegie Mellon University, October 2011, p. ix. As an employee of the US Government in official duties, his statements are not entitled to domestic copyright protection under U.S. law.

Line By Line

Here a Little, There a Little, Layer by Layer.

Back to Overview