We recently upgraded the burndown chart in the Tickets tool to include all of the key planning information on one page.  The goal of a burndown chart is to help you hit your release date.  If you run an agile development process with fixed release dates (this is almost the definition of an agile process), then please read on to learn how this simple and powerful feature can help you.

I have advocated doing without schedule estimates and task estimates, based on the following logic.  Maintaining estimates is a lot of work, and we can accelerate the schedule by applying that work to other tasks.  If we can correctly sort our tasks into priority order and work on the highest priority tasks first, then the estimate isn't needed because it doesn't change anything we do.  This logic applies if you run your own business and don't need to negotiate your deliverables with your boss or clients.  If you do need to figure out what to promise those guys, then you probably need estimates, and burndown charts will help you a lot.

Burndown charts can be simple, and they can be complicated.  Ours is the simple kind.  We do not waste any energy with the original estimates, only with the work remaining.

To use the burndown feature, you need to estimate"Work hours remaining" whenever you work on, or edit, a ticket.  This field appears on the ticket edit and comment forms.  You also need to assign tickets to a particular Milestone, or iteration, that you will burn down.

I have attached a picture of a milestone burndown below.

The orange line at the top is the burndown chart.  It shows how many work hours remaining you had estimated on each of the days in this iteration.  The goal of this process is to get to zero on our intended release date, January 10.  This chart shows a typical burndown history. 

December 30: In my management role, I entered some tasks adding up to about 20 hours. 

January 1: I showed the tasks to the other developers, and they added some tasks, and put in their own estimates, so now the total jumped up to about 50 hours.  (We didn't work on New Years, this is just an example.)

It is important that you get estimates from the developers who will do the work.  Project managers always have an incentive to underestimate.  They are optimists and they want to get a lot of work done.  Developers are also notoriously bad at estimating, but at least they have an incentive to make the estimates accurate.  They want a decent life without too much overtime or questions about missed estimates.

January 2 and 3: We did some work on these tasks.  The work "burns down".

January 4: We did some work, but we also found some bugs. The bugs add to the total amount of work, so we don't get much net gain.

You can look a this chart and see that the slope of the line is approximately correct to get to zero on January 10. However, if it stops sloping down at the right pace, then you need to change your plan.  That's why we show the two bottom panels.

Under the burndown chart is a user workload chart.  You might want to re-allocate some of the work if one person is overloaded and that is causing a bottleneck.

Under the user workload chart is a ticket details list.  This shows the biggest tasks at the top of the list.  You can probably break up or move some of those tasks.