The burndown chart isn't good or bad

The burndown chart doesn't show you how well you are doing. It shows you what is happening. That is a big difference.

I'm currently on contract through DragonsArm as an Agile Coach for a business area of a large corporation as well as a Scrum Master for a couple of great teams there.

I had an excellent question from one of the teams the other day. As their agile scrum master, I refer the team each day to the burndown chart, and I might suggest bringing items into the Sprint or dropping items from the Sprint in order to "get back on track".

The burndown doesn't look good or bad, it simply shows what is happening and allows us to make decisions

I then got challenged in this (always wonderful to see) in that we were simply trying to make the burndown look good.

Here's my response: The burndown doesn't look good or bad, it simply shows what is happening and allows us to make decisions.

Looking at the example burndown (not real), you can see that about the halfway stage (#1), the team agreed to add new items into the sprint, but, unlike #2, it didn't drop any items off the Sprint to compensate. This has the potential to overload the team.

Agile principle #8 talks about sustainability: ".. should be able to maintain a constant pace indefinitely". That means don't overload the team.

I take the burndown chart like a watch telling the time. Suppose I was tasked with clearing out the garage, which might take a whole day's work - let's call this day a Sprint.

While working, I spilled some oil which took an hour to clean up.

Now, because I included some extra work, I might decide that I don't have sufficient time left, so I can now make a decision. Either I work much harder and into the evening, finishing exhausted and affecting the next day's work, or I can leave a corner of the garage for another day and complete at the planned time to join my mates at the pub.

Of course, I could also have left cleaning up the oil for the next day, but I felt that it was dangerous to leave and therefore a very high priority and must be done now. I knew that I needed to avert a disaster.

Keeping a close watch on the burndown can help with decision making.

Keeping a close watch on the burndown can help with decision-making.

There are various methods used for ensuring principle #8, but I'm a firm believer in principle #2 which talks about welcoming change even late in development - but there is always a decision. Is the change a higher priority than some of the items in the Sprint? In my garage cleaning, I accepted that cleaning up the oil was a higher priority than some of the other work. The team (me) accepted that we would be delivering better value to our customers (also me) if we included this in the sprint (my day).

The burndown (my watch in this case) might have shown that I was well ahead and could easily clean up the oil without affecting the ability to finish the garage. Again, another decision.

Making a burndown chart look pretty is meaningless

Making a burndown chart look pretty is meaningless - using the burndown to make decisions, is an excellent use.

The burndown chart doesn't tell us how we are doing; it shows us what is happening. If your team or management doesn't know that, then it is up to the scrum master to explain that to them.

Compare this to a business chart showing turnover. Turnover doesn't tell you how well you are doing, it tells you what is happening.

Two companies, both with a turnover of $1m. One has a profit of $950k, the other has a profit of just $50k. The figure of $1m (like the burndown chart) is meaningless on its own.

These companies should both chart their turnover daily. It will tell them what is happening if the turnover rises or drops suddenly and they can make decisions - but it doesn't show them how well they are doing. That's another chart altogether.

#agile #dragonsarm #sprint