Burndown charts are one of those things that evolve over time, in accord with their agile origins. Here are some more ideas from my practice with them.
The example sheet is for the first portion of the period after Lughnasadh.
Tip 1: Pick a sprint length that fits the timing
The proper way to use agile processes is to pick a release schedule and define a regular sprint length to match that.
My release schedule is built around the six-weekly progress posts that I put up on or about the Wiccan sabbat dates*. I tried making a burndown chart for a six week sprint but it was unmanageable, hence my choice of two three week sprints to cover reach release period.
However, the next sabbat date is Mabon, the autumnal equinox, on about 21-Sep-2013. That’s seven weeks after Lughnasadh, so I have three sprints in this release:
- #1 – 29-Jul to 18-Aug
- #2 – 19-Aug to 01-Sep
- #3 – 02-Sep to 15-Sep
The Mabon sprints will then start on 16-Sep-2013, with the next goals post in the first sprint of that release. Either Mabon or Samhain (the Halloween update) will have three sprints in it too.
Tip 2: Track time off as a task
Do you work every day? Do you ever take time off?
Burndowns are built around an assumption that you have a standard amount of time available each day to do productive work**, but there may be variations within a sprint. If you lose an afternoon to a training session, then you should put that in as a task. Similarly, if you take a day off treat that as a scheduled task.
For my writing, I have found that summer activities have often made weekends unproductive so it is best to just assume that I won’t write on those days – hence in the example I have an “unproductive weekends” task to account for trips away.
Tip 3: Colour code distinct areas
This is a spreadsheet trick rather than being just for burndowns, but I like to add a bit of colour to a sheet to make it easier to navigate.
In the attached sheet I use colour to mark the headings – loading is static across a sprint and is green, while task totals/percentages are turquoise. I’ve also added an orange background on weekend days.
Tip 4: automate the repetitive bits
Burndown tracking works best when it is frictionless. The intent is to only have to change the numbers associated with tasks you’ve made progress on.
In my first agile post, I mentioned the benefit of using a spreadsheet to do the adding up. A spreadsheet can also be used to automate other things. In the example, the following components are driven by formulae:
- the copying of time remaining for tasks which have not been touched on a particular day. This is a date-based formula which looks at today’s date and the column heading date, inserting a value in the cell only if the column date is in the past and if there is time remaining on the task.
- available load. There is a cluster of parameter values in the top right: days, days per week, and weeks. These are used to calculate the “Loading” row, which makes changing sprint lengths a lot less painful.
- all the adding up. Task estimate total and percentage of load are all added up with a formula. Note that I have these as header columns which makes sense for a personal tracking chart. Things get more complicated for team projects**.
Tip 5: Record the original estimate
The initial estimate for a task is something I included in the examples in my first agile post but for some reason omitted in the actual burndown charts I made. I put initial estimates into the first day’s work instead, which was bad because the values were going to be immediately mutated by that first day’s activity.
You need to keep the original estimate for review purposes if nothing else.
Tip 6: Plan and review
You’ll see on the example sheet that there is a task for sprint planning. This is time for figuring out what the sprint goals are, and what is achievable in the time available.
I also have a cell set aside for a narrative summary of the goals, and for a review of how things went in the last sprint: did I actually get done what I thought I would? Why not?
This review is where the original estimate comes in – I can compare how long a task actually took with how long I thought it would take beforehand. In this way, I can improve my estimates by learning how long things really take rather than just using a generic estimate.
Tip 7: Keep an open mind
The most important tip in all of this is that these are observations based on my experience of using burndown charts, and what works for me. Your mileage will undoubtedly vary, so be alert to what will work for you.
So… what does work for you?
[*] not because I am a Wiccan but because it’s a nice periodicity.
[**] in a work context, there is also an assumption that not every hour at your job is productive. Between meetings, lunch breaks, and administrative tasks the usual productive time assumed for a day is six hours. I’ve set my daily load available for writing at two hours.
[***] you would usually add an assignment column so you know who is supposed to be working on something, so loading for an individual is only for those tasks that are theirs. You can into all sorts of interesting charts showing current load, load history, and so on – I used to have a colleague who was especially ingenious at coming up with new visualisations to show us how overloaded we were.