Best Practices for Reporting Metrics Using ‘Burn Down’ Charts

23FEBRUARY2018_0

Many projects these days are moving from the traditional waterfall development practices toward the Agile methodology, an iterative process for software development.  With the collaboration required among cross-functional teams, it is necessary for each stakeholder to have different metrics to understand the status and work progress to perform their role effectively.  Additionally, having the accurate status of the project enables stakeholders to make important decisions at the right time to keep the project on check.  Not only do metrics give visibility of the progress, but also the challenges that the team faced during the entire project lifecycle. It is very important to produce the correct metrics and ensure that they are simple and easily interpretable. 

Metrics for Agile projects

There are many metrics, such as Burn Up, Burn Down, and Velocity chart that are available to choose from for tracking and sharing the team’s progress during sprints and release levels for Agile projects.  A deeper understanding of the different metrics will enable the Scrum Master to determine how and when to use them most effectively in communicating progress to the stakeholders and guiding the team towards achieving the sprint goals.  

Burn Down Charts

A Burn Down chart is a graphical representation of the team’s progress, showing how quickly the team is “burning through” the stories, providing the estimated rate of work required to reach the goal.  This chart illustrates the remaining work throughout the iteration or sprint at each interval against the amount of work delivered during each sprint. Based on the chart trend, a team can manage the progress, as well as adapt and respond accordingly.  Figure 1 below shows the unit of work estimated in story points (vertical axis) with time or duration (horizontal axis) for a four-week sprint. 

Interpreting Burn Down Charts

Figure 1

figure 1

In Figure 1, although the projected actual stories line (red) is above the estimated stories line (gray), there is a lot of fluctuation occurring during the sprint duration.  The inconsistencies are due to many scope changes for reasons such as adding new tasks and re-estimating story points. 

It is the Scrum Master or Coach’s responsibility to address the scope changes happening in the middle of sprint by grooming stories ahead of upcoming sprint(s), breaking stories into smaller components, estimating stories, as well as by avoiding the addition of new tasks in the middle of a sprint.  

Figure 2

figure 2

While the sprint is behind schedule in Figure 2, the downward trend of the estimated tasks remaining suggests that team members were able to make continuous progress with far fewer inconsistencies during the sprint. The team, consequently, was able to deliver stories that were committed within the sprint schedule.      

In this scenario, the Scrum Master or Coach addresses the teams impediments (e.g. lack of collaboration, problems at the end of sprint, software issues, licensing issues) by adapting the PDCA (Plan, Do, check and Act) method to constantly evaluate the team’s progress by continually referring to the Burn Down chart and by inspecting progress against the sprint release goals and making changes as necessary.  Breaking stories into smaller components also helps to deliver stories continuously to QA for testing and, therefore, by adding value incrementally to shippable product increment.

Best Practices for using Burn Down Charts

  • Burn Down charts should be prepared, circulated and posted somewhere as the team plans to work towards Sprint goals.  By communicating it effectively, it keeps the team on track and bring about the best outcome for the team and project.
  • The Scrum Master or Agile Coach should be using it as a reference during their daily Scrum meeting to understand the available workload, scope changes, if any, and to view the trends of the sprint progress.
  • The Scrum Master should always be available for the team to provide recommendations for breaking stories into smaller components, as granular as possible to deliver continuous functionality and value to the product increment. These recommendations also help to keep the actual tasks as close to ideal as possible, enabling quicker completion of remaining work items.
  • It is the Scrum Master’s responsibility to shield the team from external influence of adding scope creep during the sprint.  They should work with the product owner to prioritize scope changes during the sprint to help the team stay more focused toward sprint or release goals, checking the progress against the overall release by referencing the Release Burn Down chart.  

In summary, it is really important for the Scrum Master or Coach to re-enforce the use of metrics to satisfy the stakeholders’ interests.  Metrics should not be used for micro-managing the team or measuring an individual’s performance but instead for reasons such as signaling to stakeholders about the team’s progress, showing transparency, helping the team inspect and adapt to meet the sprint and release goals, and improving the team’s practices.