9 February 2009
Earning up: Agile ‘burn ups’ in an economic turndown
So, the point of this post is not to explain the concept of an agile burn-up and its use in tracking project progress. Alistair Cockburn does a great job of that. Kudos to him for also explaining how Agile burn tracking was, in effect, born from Earned Value Analysis. Conventional wisdom tends to idealize that Agile project management approaches arose from the peyote induced hallucinations of a band of innovative Project Management and Architecture shamans.
To be sure, the visionaires behind Agile have significantly changed the way software gets built. However, Alistair appropriately and importantly references how these Agile PM approaches are founded on the work the government/military (further the government adapted these techniques from industrial manufacturing techniques at the turn of the 20th century).
The point of this post is to offer another simple dimension for burn chart tracking – business value. Understanding the business value of projects in general is an important part of any project. This is particularly true in the midst of a recession. Clearly, the Agile burn chart is very powerful and succinct in explaining how efficiently teams are achieving functionality goals on application development projects through story points; and Earned Value charts nicely explain the labor and material value of the functionality being developed through currency. It goes without saying that these are both incredibly important objectives.
However, in our experience, they both miss an important dynamic which can significantly improve project tracking, resulting negotiations, ongoing prioritization, and, more importantly, the fluidity, focus, and sense of accomplishment in business-technology interactions. This dynamic is the actual business value (and resulting priority) of the elements and features being delivered across the sprints in a project, and it is important to track and recognize this at least as often as you track story points earned.
You may be thinking: “priority is part of the sprint planning process, there’s no real need to include any special ‘priority value’ in the burn chart — its overkill.” Our answer would be, “perhaps.” But despite the guidance of the Agile Manifesto, many project teams tend to lose connection with business priority and many business stakeholders tend to get lost in the minutiae of giving guidance on features while losing sight of which of these features are going to give them the most bang for the buck.
So, we think we have a simple solution: add a secondary measure to the Agile burn chart that captures the business value of the feature/functionality being delivered. Now, Cockburn hints at this, but we believe its a vital part of increasing communication flow and focus on business benefit. To accomplish this you simply add a secondary y-axis to the normal burn up/burn down chart. So on one y-axis, you could have story points, and on the other y-axis you would plot something more tangible to the business (in this example – estimated revenue). This could also be: customer complaints reduced, widgets manufactured, product returns averted … you get the idea.
So, you might have a table such as the one below that gives you the raw data for your burn chart.
This table would then be used to generate the following “Earn up” chart.
The ideal way to draw this graph is using one line plotted against two axes – one for story points and one for business value. However, by default, excel is not very intuitive to use in this regard. So, its likely easier to create a combination chart to represent what your team is earning on their project as we’ve done here with the bar/line combo chart.
Technorati Tags: agile pm, agile project tracking, burn charts, burn up, burn down, earn up, earned value management, agile manifesto, alistair cockburn
Nice article. The hard question is, “how do we find that business value?” Usual agile features and stories are too fine-grained for most people to attach $ value to. In “Software by Numbers”, Mark Denne and Jane Cleland-Huang introduce the term “minimum marketable feature” as something coarse-grained enough to do that with. I still haven’t seen someone pull this off in real life.
Little historical note… It’s quite possible that burn charts did indeed arise from “the peyote induced hallucinations of a band of innovative Project Management and Architecture shamans” (lovely image :)… I, for example, never heard of EVM until I’d been using burn charts for 5 years. Then, when I finally arose from my peyote-induced stupor and was shown one of these things, recognized it was the same thing. I have no idea whether or when the Scrum inventors first saw EVM. However, I’m always looking for bridges to make it easier for people who already know something to apply that in the peyote universe (as opposed to people who try to maximize the difference), so I try to maximize the overlap between them in descriptions.
Again, nice job – please post or email me if/when you can show an anonymized but real-project version.
Alistair