Man, I love burn down charts. I also love that the writers of Silicon Valley knew that this is what nerds do when we’re scared: we chart data.
I found burn down charts a couple of years ago, as part of some reading on agile software development. It’s just one, minuscule aspect of the methodology, but it’s the one that clicked with me. When I’m overwhelmed by the scope of a project and I’m on deadline, making a burn down chart is my personal therapy. It doesn’t matter if the chart is accurate, or if no one but me is looking at it. If the chart exists and I can update it, I feel better.
A burn down chart shows the total hours of work left to do on a given day (Y-axis), charted over a span of days or weeks (X-axis), given that an incremental number of hours will be spent on that work per day. I’m in the midst of a good-sized project with a quickly-approaching deadline right now.
This is my burn down chart:
You can see I have good reason to be pretty smug at the moment, because my hours remaining is well below the ideal burn down. That’s because on Thursday I had a “holy crap I’m behind” moment and did a few intense code sprints. I try to make my time estimates extra-conservative, so I finished tasks sooner than I expected. The result is I’m a lot more relaxed this weekend because we’re well on track.
At ThinkUp we use Trello to track and discuss tasks, an app I love so dearly I’m willing to overlook the things about it that bug me. To make my burn down chart, I use Burndown for Trello (BfT). BfT isn’t the prettiest app on the block, but it’s functional. To use Bft, on your Trello board, add a time estimate in parentheses before the title of the card, and then add hours you’ve spent on that task in square brackets at the end of the title. (That means a task in my current board could be (10) Retrofit the flux capacitor , which means I estimated the task will take 10 hours, and I’ve spent 5 so far.)
Then, you connect BfT to your Trello board and enter your project deadline into BfT. BfT generates your chart, based on hours estimated, hours spent, and what day you plan to be done on. It even has a handy “I don’t work on weekends” setting that assumes there’s no burn on Saturday and Sunday. (That’s why the “ideal burn” line on my chart above looks more like a staircase than a diagonal line.)
This is the only way I’ve ever found to accurately guess whether or not a longer-term project is on track to ship on time.
The other advantages of a burn down chart? Just to make one, you force yourself to do two of the hardest parts of software development first: 1. breaking down a big project into small, discrete modules, and 2. estimating how many hours coding, testing, and deploying them will take. Once the burn is over, you can check your work, and see what you overestimated and underestimated, which helps you get better at estimation overall.