Ok. So I have a team and I'm looking at their board. On that board, if they are like 90% of the teams out there, they will have a burn down chart somewhere. Let's take a closer look at the burn down shall we? Does it, as so many do, show a flat line until the day they all update the tool at the end of the sprint? Does it show a nice progression of tasks done over the sprint but at the end of the sprint are there no stories completed because they worked on everything at once? 

The burn down is one of the classic tools for an agile team. Everyone does burn down charts. Mostly they do them badly. Over the years I have come to dislike the burn down chart for a number of reasons. Chief among those reasons is that it really doesn't do what it is supposed to - give an indication of whether the team is going to achieve its sprint goal. On the surface it looks like it should - there is a list of stuff to be done and a rate at which it needs to be completed to meet the date but in reality, the burn down doesn't give a very good indication of where things really are. The other big problem is that while they are supposed to be easy, most teams find keeping a burn down chart up to date a massive headache. So let's take a look at the burn down and some of the things that cause teams pain. We'll also look at a really good way to replace it completely.

Let's start with the classic burn down anti-pattern - the flatline. We've all seen this one. The "to do" line that doesn't move until the last day of the sprint when everyone updates the tool and suddenly the team gets everything done in a day. This, of course, is not a reflection of the team's progress but in how well they (or more commonly their poor scrum master who gets lumbered with the job) keeps whatever tool they are using up to date. The chart is basically useless. So why not keep the tool up to date? "Because", says the team, "we are moving the cards on our physical wall, updating the tool is double handling". This usually leads into yet another discussion about whether they can ditch the physical wall and just do everything online and at that point I usually find myself rapidly losing the will to live.

Of course, if you do shift to an online board, the tool still doesn't get updated because no one ever updates the tool. Ever. Tools are an information refrigerator. You have to make a conscious decision to stop doing what you are doing, open the tool, then navigate to the menu, wait for it to load, and make your updates. You can't just move a card as you wander past on your way to the kitchen for lunch.

Most teams rely on a tool to generate their burn down and most tools are really, really inflexible about how they generate the chart. Most of them generate the chart based on task hours remaining which locks you into using tasks, estimating them in hours, reporting time remaining each day and even worse, then managing them in the tool rather than on your VMB where they belong. I'm not a huge fan of task hour estimates and would much rather teams just make the tasks a day or less. Tools though tend to lock you into the "classic" process with all the overhead that comes with that.

Of course not using a tool means that someone, usually the poor scrum master again, is stuck with the task of manually calculating the burn down each day. It's not hard, just tedious and this means that it usually never gets done.

One way around this is to use a tool that does a story level burn down so as each story gets done it burns off the appropriate number of points. If you find a tool that does that, let me know because I have found exactly zero so far that will let you do that. The other cheat is to just make all your tasks the same size - 1 so they are either done or not done. That takes some of the overhead out. It doesn't fix the main problem with a task level burn down though which is that it really tells me nothing about whether the team will meet its goal.

What I am really interested in is whether the team will complete the stories it committed to. I really don't care about tasks. They can complete an awful lot of tasks and still not get any stories to done. The classic anti-pattern there is the team that completes 95% of their tasks but none of their stories because there was at least one task per story not completed. A burn down of tasks won't show you that. You might as well have a chart of lines of code completed. You need to take a really good look at their board to see what will and won't be finished. But the whole idea of a burn down is that it's a big visible information radiator that should prevent the need for a minute examination of the board. It really doesn't do the job it's supposed to. The burn down hides the real information because it focuses on the wrong level of detail.

A story level burn down would be better but as there are no tools that support it, that means it needs manual calculation. It also suffers badly from the flatline problem but for diferent reasons. In this case the pieces of work are generally large enough that they don't get done in a day, so the chart stays static for days at a time as the teams works on finishing a story. Write smaller stories you say, well yes, but there are limits. Having the team break everything down into 1 day stories is probbaly a step too far. And the chart still doesn't tell me which stories are in trouble, only that there might be stories in trouble. I have to study the board again.

What I want to see is a big, clear, visible indication, on the team's board, of which stories will be completed by the end of the sprint. One that doesn't need a tool to be updated. One that doesn't need calculations. Fortunately, such a thing exists. All the team needs to to is put a confidence indicator next to each story card on their board. Thumbs up = confident that this will be done by the end of the sprint, thumb sideways = not confident that it will be done, thumbs down = almost certainly won't be done. Or use red/green/orange or happy/sad/meh faces or whatever you like. Update them as part of the standups.

So now when I look at the board, I can see at a glance what I need to be concerned about. The board has become an information radiator again. I can scan the boards, look for the thumbs down or thumbs sideways and focus my attention there.

So why not try an experiment this year - ditch the burn down and try confidence indicators instead? You can even use them at the feature level on program level boards as well.