Fundamentals of Applying Earned Value Management on Agile Programs

Love it or hate it Earned Value Management (EVM) is a reality on many Government programs.  Yet people in both the EVM and Agile communities have been heard to say that EVM and Agile were inherently incompatible.  Hogwash.  We’ve been doing it for years.  In fact, not only is Agile compatible with EVM, but Agile provides extremely rigorous data for determining percent complete and for forecasting. This briefing will describe core principles and techniques for performing EVM on Agile programs.  The methods described show how the natural working of Agile teams developing Epics, Features, and Stories can provide the underpinnings for EVM metrics.  The briefing will also include lessons learned and remaining challenges as we work with our government partners to define common guidelines.

 
1 favorite thumb_down thumb_up 2 comments visibility_off  Remove from Watchlist visibility  Add to Watchlist
 

Outline/structure of the Session

Key topics will include

  • Why we need to perform EVM on Government programs
  • Core EVM concepts
  • Using the Agile backlog and roadmap to underpin the Performance Measurement Baseline
  • Using Features and Stories to compute EVM percent complete
  • Lessons Learned & current challenges
  • Broader government and industry perspectives

Learning Outcome

An understanding that EVM requirements on Government programs are not a barrier to Agile adoption.   

An understanding of the core principles for effectively computing EVM metrics on Agile programs.

Target Audience

Leaders, Program Managers, Coaches supporting Government programs, Anyone working Agile programs with EVM requirements

schedule Submitted 11 months ago

Comments Subscribe to Comments

comment Comment on this Proposal
  • Paul Boos
    By Paul Boos  ~  10 months ago
    reply Reply

    What approach are you taking? There are dozens... Just curious as this is something I have crossed now for about a decade and I am wondering if there is something new here.

    • Robert Eisenberg
      By Robert Eisenberg  ~  10 months ago
      reply Reply

      Essentially it comes down to this.  EVM requires us to measure product, not time (you can’t perform EVM by measuring progress against cadence based releases or sprints).    If you are doing EVM it’s assumed that you have well-defined product scope (by contrast, if you are “level of effort” you wouldn’t even be doing EVM).  Product is defined by the backlog.  So, you start with a backlog that defines the product scope in large chunks (let’s call them “epics”).  Budget is mapped to the epics.  This mapping is critical since budget must be tied to scope.  You now decompose the epics into smaller chunks, let’s call them features (which are sized relative to one another).  Features will have well defined acceptance criteria and be the smallest size chunk of product that can be tied to program scope.  We usually talk about the size of features as something that can be completed in 2-4 months.  For implementation we decompose the Features into Stories.  Stories, however, do not define scope, they are a means to implement the scope defined by the features.  This is important to prevent the addition or deletion of stories from causing complexities.  Progress is then measured based on the completed stories (typically weighted using story points). 

      So, let’s take a very simple example, using one epic that we want to measure against.  For simplicity let’s assume this epic has two features, FeatureA and FeatureB, and that FeatureA has been estimated to be twice as big as FeatureB (and thus will have twice as much budget).  Work is started on FeatureA, but not FeatureB.  Four stories are defined for FeatureA as follows:

      • Story1: sized as 5 story points
      • Story2: sized as 8 story points
      • Story3: sized as 5 story points
      • Story4: sized as 2 story points

      Development has begun and we want to measure status.  This can be done at any point in time, it doesn’t have to be a sprint boundary.  Let’s assume at this point in time I have completed Story1 and Story3.  FeatureA percent complete is (5+5)/(5+8+5+2) = 50%.  Epic percent complete is 33% (50% * 2/3), since FeatureA was twice as big as FeatureB.  Standard EVM metrics (e.g., CPI, SPI) can then be computed.  For example, CPI can be computed by using the percent complete values described and the financial information from the company accounting system (i.e., how much have we actually spent building this product relative to it's allocated budget). 

      Of course there is a lot more detail (like how to manage change at the Feature level), but this is a high level overview.  We (Lockheed Martin) have been working with our industry partners and Government agencies on this topic for several years to establish common and accepted practices.  This briefing will reflect the results of that collaboration.  The fundamentals of the approach described has become that accepted practice.  Many of those "dozens" of approaches you reference wouldn't pass a government audit. 

      I hope this helps.  If anything is unclear let me know.