7 April 2009

Alistair Cockburn on Earned Value and Product Burn Charts

A big challenge in implementing agile practices is overcoming prejudices and managing the language/expecation gaps - to stop them becoming barriers to getting work done.

One tool to help people is the close links between agile burn charts and project management's earned value. Inspect the two models, they are almost identical as far as the outcomes they generate.

Cockburn's article is here.

Picture by Tracy O, CC$ Flickr


  1. Anonymous3:00 pm

    While Alistair has co-opted the term "earned value" to be the same as his burn down chart - it is NOT.
    There is no measure of efficiency or "earned value" as part of the chart.
    As well, there is no monetized Budget At Completion (BAC), so the Estimate To Complete (ETC), and Estimate At Completion (EAC) can not be derived.
    This is one of those situtaions, where the agile community has redfeined a term that has a clear, concise and "legal" definition (Defense Contract Management Agency and EIA-748B).
    It's too bad, because EV is used in agile software projects, just not the way Alistair defines it.
    My attempts to explain this came to naught.
    As well a stable baseline is needed. "Rubber banding" the baseline is a common cause for project overruns, frequent re-baselining hides past performance. All cause for Corrective Action Reports by DCMA - an all around bad things.

  2. Glen

    In using a burn down chart I am producing a forecast of BAC, but this is based upon the premiseof a steady cash burn rate. The peaks and troughs have been flattenned by removing much of the specialisation of roles.

    You definitely see planned value and earned value. Tasks are either done per the forecast or not (as happens on all sensible projects, as you note on your blog.)

    And SPI etc also fall out of it.

    Is he issue that budget is not specifically addressed? Is so then what happens if you assume time=money?

  3. Any time I see a straight line in the planned line of a burn-down chart, I know that this project is going to have a nasty surprise at the end. That is because there is always discovery in almost any project and a straight line means that the developers weren't allowed to revise their estimates.

    You might be interested in this lecture that I gave at Brooklyn College where I presented ways of advocating process including selling burn-down charts to both management and engineering.

  4. Sure the line changes over time. And managing people's expectatins around the 'estimate' thing i a constant battle.

    Thanks for sharing the lecture notes.

  5. Anonymous3:19 am

    You've hit the problem. On "real" earned value project Time <> Money in general. This is the case ONLY on Level of Effort projects. In that case it's called "train watching" and EV provides little value.
    The other challenge with the Burin Down chart is what "should" the Budgeted Cost for Work Performed (BCWP) be at that point in time. The Burn Down chart is a very useful visual for agile and traditional project, but it is NOT equivalent to Earned Value.

  6. Anonymous3:29 am

    The real problem - and this is a personal problem - is the redefinition of the term "earned value," under the guise of agile burn down charts.
    EV is defined in ANSI/EIA-748B

    Anything other than this and the Intent Guide http://www.acq.osd.mil/pm/historical/evms_pol.htm

    Now this stuff is over the top for agile projects, but renaming established terms is simply wooly thinking, a common practice in some agile groups.

  7. Anonymous3:38 am

    I appolgize for labeling my posts with Paul. Paul Ritchie is the PMO for SAP.
    I spend the majority of my time with you - Craig - and Paul.

  8. thanks Glen

    I really appreciate your contribution to this discussion.

  9. Alistair his-self wrote me an email on this post and highlighted the fact that

    a) He isn't equating EV to burndowns, and
    b) Agile progress tracking has a very important difference to EV; It tracks working software and not just activities.

    Writing this down now I realise that Glen is also focused on that type of deliverable at a Work Package level (if I have the right terminology.)

    Written communication is soo much harder than coversations...

  10. John Rusk in New Zealand just got an article on this topic published in Software Tech News, an American DoD magazine. Republished on the web at http://www.agilekiwi.com/agile_charts_part_ii.htm. I think his version will be closer to DoD terminology than anything I can write.