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