My journey through burn-down charts.
The burn-down chart is one of the staple artefacts of Scrum; in fact, it’s difficult to imagine a team without one. However, what should a team capture on their burn-down chart; hours, tasks, story points (or equivalent), something else, or a combination of the above? I have tried various approaches and found some are better than others, depending on the context. These are my findings thus far.
It’s worth noting that I am focusing this post purely on burn-down charts within a sprint or iteration, and not beyond, into releases or portfolio level.
First of all, here is a quick recap of a burn-down chart. It's an excellent way of visualising the the amount of work remaining across a period of time. As each day passes the team plot the remaining work (on the vertical axis) against the reaming days (on the horizontal axis). As can be seen from the following chart, one can immediately have a sense for the status of progress.
Like all artefacts in Scrum or any agile framework, the primary existence of the burn-down chart is to serve the team. It is there to help them understand how they are progressing through the current iteration and provide a visual indication of any problems with regards to progress. However, whilst it can be useful for members outside the team it should be used with caution. It is often seen as a progress report, but it does not always represent the full picture and can easily be misinterpreted. To illustrate this, let’s have a look at some burn-down charts.
The first question is, what should the team capture to indicate remaining work – what should be on the vertical axis? One of the most common, and often the default for a lot of teams that I encounter, is remaining hours.
Each day, usually after the daily stand-up, the team total up the number of hours of all the tasks that are not done and plot this value on the vertical axis for that particular day. Whilst it is intended the team capture the number of hours required to complete all remaining tasks, this is rarely what is captured. Firstly, the complex and emergent nature of software development makes it very difficult to actually know how many hours are still needed to complete the remaining work; secondly, the hours initially estimated at the beginning of the iteration are usually inaccurate anyway. So the actual hours which are plotted on the chart are rarely a true indication of remaining work. At best, team members may know how many hours are remaining for a task already in progress, since knowledge has been gained as the task is worked upon; however, the other tasks that are not started still have estimated hours which are usually inaccurate. Plus there is an extra burden on team members to gauge, at least daily, how many hours are still needed. Trying to work this information out is difficult and a distraction from the focus of writing and delivering working software. As a result, the chart often burns down linearly, even though at the end of the iteration there is a large amount of incomplete or remaining work. This is because the team tends to track the hours they have actually worked, rather than the hours remaining.
One way to validate this is to look at the number of tasks at the end of the iteration and see how many have their initial estimated number of hours updated. And even if they do, total up the number of hours of completed tasks and compare them to the number of hours available in the iteration – I bet they don’t even come close to matching!
This is not the fault of the team or its members; it is due to the complexity and uncertainty of developing software products. It is an indication of focusing on the wrong thing. Trying to estimate the number of hours to complete many tasks when there is little prior knowledge of what needs to be done will always be inaccurate – so don’t waste time trying!!
So burning down on hours usually results in a nice looking burn-down chart, even when there are major problems in delivering what is forecast for the iteration. It can lead to a false sense of security and not provide true transparency. Plus, if used in isolation by someone outside the team, as a reporting mechanism, it does not provide a true picture of the real situation. So, if burning down on hours is not so good, what about tasks, maybe this is a better option?
Burning down on tasks is certainly easier to do. At the start of the iteration the total number of tasks required is counted, and as each day passes, and tasks are completed, the new remaining (unfinished) number of tasks is plotted on the chart. The effort to do this is as little as the time it takes to add up the number of tasks not complete. As the iteration progresses additional tasks, that were not identified upfront, will emerge. As these are added to the task board, and the chart is updated, small uplifts on the burn-down chart will appear. This is normal and ok, it simply shows that emergent tasks are identified and captured on the chart. Therefore, it shows a more representative view of the remaining effort, but this too can have its limitations.
The team may be burning down tasks at a good rate and the chart will look normal; however, completing tasks is not the goal of the iteration - completing shippable product increments is. So whilst the burn-down chart can show lots of tasks completed, the iteration can still end with several user stories not complete. To demonstrate this one can also plot Story points (or equivalent) on the burn-down chart. Story points burn down only when the entire story is done. The amount burned down is the user story’s point value, the relative size of the story. The chart below is an actual chart from a Scrum team I was coaching and shows this situation.
As the chart indicates, the burn-down of tasks shows the team are progressing reasonably well. However, the number of actual story points completed is not burning down, at least not until the end of the iteration. This indicates the team start user stories, but before completing them, thy start more user stories. This indicates the team probably has too much work in progress (WIP) – that is, working on too many parallel items. Limiting WIP is key to ensure a team do not multi-task to the extent that it slows down progress. In the meantime, as the chart shows, burning down on tasks alone can also indicate everything is ok when in reality, it is not.
So if a burn-down chart showing only tasks is used, it is better to also capture the burn-down of story points too. Or better still, just burn down on story points alone and forget tasks. After all, the task board gives a visual representation of the number of tasks still to be completed. Having said that, burning down on story points alone does not alert us to having too much WIP, so how can we visualise that too?
So ideally we need a burn-down chart that captures story points, but also alerts us if there is too much WIP. To achieve this we can plot 2 lines. The first line (shown in blue on the chart below) burns down by the number of story points for each user story either in progress or done. So as soon as a task is started, the corresponding story points of the story to which that task belongs is burned down. In other words, all the stories that are either in progress or done have their story points totalled and the value is plotted each day. The second line (shown in green) is similar, except that it is the total number of story points that are done. As soon as a story is completed and considered done, the total value of all story points of completed stories is burned down. This second (green) line is the important one since this represents actual user stories completed, which is the real indication of progress within an iteration. However, the area between the 2 lines, shaded in red, is the WIP! The larger the shaded area is, the greater the WIP. The aim is to keep this shaded area small, a thin channel running through the chart, indicating a small WIP.
A minimal WIP is desirable as it shows the team are focusing on seeing a user story through to completion before beginning more stories. Having a constant flow of completed stories, and watching out for a large WIP, is beneficial for a number of reasons;
The Product Owner can see regular real progress rather than a “big bang” completion at the end of the iteration. This can also provide an opportunity for early feedback on completed stories, which in turn can influence the direction of future user stories on the backlog.
Once a story is done, it’s done! Having 5 stories done is far better than say 8 stories 90% done. There is little value in almost complete stories – the team should focus on getting a small number of stories complete, rather than having many stories in progress at the same time. This is all about reducing the inefficiencies of context switching that multi-tasking brings about, but that’s another blog post ☺.
Stress levels of the team reduce as each story is completed. At the start of the iteration, the team should feel the most pressure, since all the identified work is yet to be done. As each story is completed, the pressure on the team reduces bit by bit. In fact, the second green line on the burn-down chart pretty much shows the team’s stress levels. As stories are completed the pressure reduces, which is much more desirable than the pressure building as no stories are completed and the end of the iteration draws closer.
Team members should work closely together when executing the stories in the iteration. If there is a large WIP this may also indicate that team members are working in isolation – one team member working on one story for example. This may seem efficient in the short term since lots of items are in progress, but it is not. I think this requires further explanation, but for the time being, this should be avoided.
If a constant flow of completed stories cannot be achieved it can also point to other concerns, such as user stories being too large.
So to summarise - I have experimented with various burn-down charts with various teams and find tracking story points to be the most effective, especially when WIP is also captured. I have also flipped the chart “up-side-down” and created burn up charts (see below). Sometimes team members prefer this type of visualisation, but the essential information is still the same.
It will be good to know if you have tried any alternative ideas or have any thoughts about the above.
Thanks for reading ☺