Agile Zone is brought to you in partnership with:

Kelly Waters is Web Technology Director for IPC Media, one of the UK's largest publishers of consumer magazines and web sites. Kelly has been in software development for about 25 years and is a well-known narrator of agile development principles and practices, as a result of his popular blog 'Agile Software Development Made Easy!' ( Kelly is a DZone MVB and is not an employee of DZone and has posted 40 posts at DZone. You can read more from them at their website. View Full User Profile

Track Your Agile Projects with a Project Burndown Chart

  • submit to reddit

Agile project management often needs more than the practices provided as standard by agile methods. Tracking project status is one area where I think that’s true.

Scrum includes the concept of a Sprint Burndown Chart.  For those that aren’t familiar with it, it’s a simple yet very powerful concept. Here’s how it works…

At the start of each Sprint, the team has estimated the work they plan to complete in the Sprint, either in hours or in points.  The burndown chart has the days of the Sprint across the bottom axis.  On the first day of the Sprint, the number plotted on the chart is the total planned time or points for the Sprint.  Each day, this total is reduced for any items that are completed, so the total gradually reduces, hopefully until it reaches zero at the end of the Sprint.

You can also draw a target line from the top left of the chart to the bottom right, assuming that every day the same number of points or hours are ‘burnt down’.  If your actual line is below the target, you’re on track.  If it’s above, you’re falling behind.

And that’s the beauty of the burndown chart.  You can see very clearly – literally at a glance – how the team is doing against their Sprint plan.

Extreme Programming, by the way, has the same concept, but in XP you burn up rather than down.

So what’s a *Project* Burndown Chart?

Well it’s simple really…

It’s an adaptation of the Sprint burndown chart, designed to give you the same sort of clarity, but at a project level, rather than for an individual Sprint.

Use a similar format to the daily Sprint burndown chart, but instead of days along the bottom, put Sprints.  At the start of the chart, plot the total size of the Product Backlog for the entire project.  For your target line, reduce the number for each Sprint by your target or forecast Velocity (the number of points or hours you expect to burn down in each Sprint).  As you complete each Sprint, reduce your actual number by your Velocity and the actual line will start to come down, hopefully as fast as your target line!

Here’s an example of a project that hasn’t gone to plan:

Agile Project Burndown Chart

And that’s it!  It’s as simple as that.

When you have a project that spans multiple Sprints, it can be hard to keep track of where you really are.  With a Project Burndown Chart, it’s easy.  And best of all, it hardly takes any time at all to produce and doesn’t require you to do any additional planning.

I’ve never seen a Gantt chart and traditional status report provide the same incredible clarity that a Project Burndown Chart does.  It’s brilliantly simple, and it’s quantitative, rather than a matter of opinion.

If you have multiple projects on the go, across several teams, there is no quicker way to know which projects are on track and which are struggling, and with a fraction of the paperwork and effort of a traditional PMO (Project Management Office).

Published at DZone with permission of Kelly Waters, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Shumona Kapil replied on Sun, 2012/02/19 - 10:11am

I recommend using a project burnup chart, instead. A project is not a known size. In fact, if you don’t learn something that alters the scope along the way, it’s arguably not an Agile project. We should always be learning.

A burndown chart does not gracefully handle changes in the size of the work to be done. It’s got a natural fixed goal line at zero. If you leave this fixed, then changes in scope get displayed the same as work done (or undone).

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.