Burn down chart

Burn down chart

I have been asked more than once about what to do with tasks that occur during a sprint that are not directly related to a committed story.  You need to first determine 1) whether the teams commit to the task, and 2) whether it is generally helpful for the team to account for the effort and burn it down.  Tasks can be categorized to help determine whether they affect capacity or need to be planned and managed at the team level.  Tasks that the team commits to performing need to be managed as part of the teams capacity while administrative tasks reduce capacity.

Administrative tasks.  Administrative tasks include vacations (planned), corporate meetings, meetings with human resources managers, non-project related training and others.  Classify any tasks that are not related to delivering project value under administrative tasks. One attribute of these types of tasks is that team members do not commit to these tasks, they are levied by the organization. The effort planned for these tasks should be deducted from the capacity of the team.  For example, in a five person team with 200 hours to spend on a project during a sprint (capacity), if one person was taking 20 hours of vacation the team’s capacity would be 180 hours.  If in addition to the vacation all five had to attend a two hour department staff meeting (even an important staff meeting), the team’s capacity would be reduced to 170 hours.  Administrative tasks can add up, deducting them from capacity makes the impact of these tasks obvious to everyone involved with the team.  Note: in organizations that have a very high administrative burden I sometime draw a line on the burn down chart that represents capacity before administrative tasks are removed. 

Project-related non-story tasks. Project-related non-story tasks are required to deliver the project value.  This category of tasks include backlog grooming, spikes and retrospectives.  There is a school of thought that the effort for these tasks should be deducted from the capacity.  Deducting the effort from capacity takes away the team’s impetus to manage the effort and the tasks. This takes away some of the team’s ability to self-organize and self-manage. The team should plan and commit to these tasks, therefore they are added to the backlog and burned down. This puts the onus on the team to complete the tasks and manage the time need to complete the tasks. As example if our team with 170 hours of capacity planned to do a 10 hour spike and have three people perform sprint grooming for an hour (total of 13 hours for both), I would expect to see cards for these tasks in the backlog and as they are completed the 13 hours would be burned down from the capacity.

Tasks that are under the control of the team need to be planned and burned against their capacity.  The acts of planning and accounting for the time provide the team with ability to plan and control the work they commit to completing.  When tasks are planned for the team that they can’t control, deducting it from the overall capacity helps the team keep from over committing to work that must be delivered.   

Metrics Minute:  Burn Down Charts
Thomas M. Cagley Jr.

Audio Version

Definition:

Burn Down Charts are a graphical representation of the work left to be done and of the progress that has been made. The chart is typically drawn to show progress against predictions. The analogy of a glide path has been used to paint a picture of the slope and the ultimate destination of a burn down chart which targeted at completion. One of the most powerful attractions of the burn down chart is that it involves psychology by emotionally tying the metric to completion through the visual representation of a path counting down to zero. 

Formula

There is not really a formula for a burn down chart as much as there are instructions on how to represent progress against a goal graphically. Burn down charts are represented as a standard x/y chart. The x-axis is used as a representation of time. Typically days are used although I have seen charts that span multiple sprints so denominators such as months, milestones or sprints are occasionally used. The y-axis is denominated in units of work (for example story points or hours of effort). The line that connects the total amount of work to be done in the sprint and the length of the sprint is called the ideal line. This forms an isosceles triangle. In most burn down charts the amount of work remaining is also drawn between the two axes then compared to the ideal line. The difference between the two plots represents whether the project is ahead or behind schedule.

 

 Uses

There are two primary uses of a burn down chart; planning and monitoring. The burn down chart represents either what is intended to be delivered in a sprint in terms of stories or the amount of effort that is intended to be expended to deliver the agreed upon functionality. Through the quantification of what a sprint intends to deliver based on the estimates of the team and historical velocity, the chart represents a plan (a weakness for some that we will discuss later). The power of visual planning is even more evident when burn down charts are used for sprint and release planning for large programs.  

The second primary use of a burn down chart (and maybe the most important) is for monitoring and control based on the visual representations of the plan and progress against that plan. At a glance, the chart can tell whether you are ahead or behind schedule which provides the team with the impetus for action. For example, if progress is not being made fast enough additional effort can be brought to bear or scope can be reduced. Alternately, if progress is racing ahead of the ideal line, additional work can be accepted into the sprint.

Issues

A burn down chart can look like a roller coaster ride rather than the smooth slope that a glide path evokes. This saw toothed pattern reflects that both tasks and stories are not completed at the rate shown as the ideal slope. This rougher pattern suggests that it is important to know when a gap between the ideal and actual performance reflects a signal that action needs to be taken rather than the noise of the normal flow of work.  One solution I have seen used is to create a set of control limits (as if the burn down chart was a control chart) to create signals. Limits require making many assumptions about process discipline and capability that might not make sense. I would suggest that the use of mechanistic guides should only be used as a measure of last resort or perhaps as a set of training wheels. Rather, I would suggest relying on the judgment of the scrum master and team to provide the guidance needed to direct the sprint based on a strong definition of done.

 A second issue is that a burn down chart provides visibility at a high level rather than progress at a story level which causes some people concern. Burn down charts are not designed as a precise report on where each story is on a day-to-day basis but rather as a view of how much work is left to be done and whether the team is on track to meet its sprint goals. Those who expect the chart to have the same precision as a detailed schedule will not have their needs met. In order to meet the needs of those that need precise knowledge of individual stories, I would suggest a visit to the card wall or its proxy is a better source than the burn down chart.

An effective burn down chart used for monitoring and tracking effort needs to reflect the amount of effort required to complete the work defined by the sprint at specific point in time. In order to deliver this type of information the actual line can’t be a pure reflection of what is left of time originally planned rather it means that the actual line is something that is more like using earned value. The tracking of work remaining for any open task must become part of the daily rituals of the sprint team. I suggest that work left on a task be collected during the standup meeting and captured in the tool being used to track stories and activities. In one organization I was involved with a user field in TFS was created to track this data. Using this method, the actual line will reflect what needs to be done rather than just what was planned to be done.

A final issue with burn down charts is that it is not always easy to reflect changes in the number of stories while in flight. One simple alternative is the burn UP chart. Another options is to increase (or decrease) the ideal line at the point where the scope was changed or to extend the ideal below zero to reflect additions to scope. The former option is the one I suggest. This option can also be used when there are specific events that consume a significant amount of effort that are not spread evenly across a sprint.  

Related or Variant Measures

  • Functional Size
  • Velocity
  • Burn Up Charts
  • Earned Value
  • Productivity

 

Criticisms

The single most heard criticism is that a burn down chart does not provide as much status information as a project schedule or detailed status report (definitions vary). I would argue that the data presented is equivalent and if produced daily that it actually provide more actionable information and far less excuses. The real issue is that it is different and because it is different training and education are required. I do not suggest phased transitions as it is to easy to hold on to the past.

The false signal issue is a fair criticism. The saw tooth pattern seen in both effort and story denominated burn down charts require a conversation with the scrum master or team lead before reacting. Building an understand of how to interpret the burn down chart and building trust in self directed teams to see the trends and to take action themselves is critical for making a transition to this form of progress and status reporting.