Scrum Team Mechanics: Burndown Chart

Published 11/28/2018 03:18 PM   |    Updated 12/03/2018 08:05 AM
This article originally appeared on Sept. 28, 2017.

A burndown chart is a graphical representation of forecasted work completed over time. It was initially introduced by Ken Schwaber in 2000 and is extensively applied in Scrum Agile development. 
 
The graph illustrates progress made toward the Sprint forecast by showing how quickly a team is burning through the product backlog items chosen for the Sprint (often estimated with Fibonacci sequence numbers). This allows team members to regularly inspect and adapt while maintaining visibility to the Sprint forecast and self-organizing around the Sprint goal.
 
Despite their popularity in Scrum, burndown charts can be applied to any project, as long as the project contains measurable progress over time. Moreover, burndown charts are regularly used for release trending/forecasting.
 
 
The structure of a burndown chart is straightforward. The y-axis represents the amount of remaining work (can be measured in user stories, hours, etc.), and the x-axis represents the time frame, which is identified in advance. 
 
Prior to being selected for a Sprint, the team works regularly to review and estimate prioritized product backlog items during backlog refinement. Once the items are selected by the team at Sprint planning, the total amount of work represents the Sprint forecast. 
 
The burndown chart begins at the point of the total forecasted amount (all estimated/remaining work for the current sprint) and burns down as the team completes the work. As a result, the accumulative effort versus the amount of work the team delivers can be seen at every point in time.
 

Benefits of applying

 
Burndown charts are an essential Agile metric/reporting tool. They increase visibility into the overall team progress while facilitating conversations with the product owner and team by visualizing the impact(s) of decisions made throughout the Sprint (i.e., adding/removing user stories, capacity constraints, blocked stories, impediments, etc.). They’re a perfect tool to track the state of the project, team velocity and completed/remaining work.
 
A burndown chart is a very effective tool to communicate forecasted performance and encourages everyone on the team to resolve issues sooner and more decisively. For this purpose, burndown charts should always be visible to the team and, in best-case scenarios, updated by team members to increase their ownership and improve collaboration. 
 
The simplicity of a burndown chart makes it a perfect tool for a team’s self-effectiveness evaluation. Another important aspect of burndown charts is their motivational impact. Seeing the line creep ever closer to zero has a psychological effect on team members, motivating them to collaborate toward the Sprint goal.
 

Common pitfalls

 
The most common pitfall of burndown charts stems from the accuracy of initial estimation. The position of the actual remaining work line (which can be above or below the estimated remaining work line) fully depends on the accuracy of original estimation. As a result, a team can constantly underestimate or overestimate time requirements, just because of the initial wrong estimation. 
 
Another important concern is that simple/standard burndown charts show only completed work. There’s no indication of changes in the scope of work as measured by total points in the backlog. As a result, changes in the burndown chart may or may not represent actual changes in the product backlog. 
 
Finally, burndown charts show continued progress, but they don’t show whether the team is working on the right product backlog items. Therefore, burndown charts are a tool used to track progress, identify trends and motivate team members to self-organize around the Sprint goal/forecast.
 

Know what you see.


Projects are different, and people are unique. But sometimes we can see trends that are very similar across different Sprints. Recognizing trends can help us identify issues at an early stage and resolve them before they get worse. Burndown charts can reveal many common trends, such as: myth, envisioned dysfunction, commitment difficulties, exceeded commitment, scope creep and delayed report.
 
  • Myth — In this burndown chart, we can see that actual remaining work at every single point in time is slightly less than estimated work. That means our team equally completes estimated work over the whole period, which is practically impossible. Although it could happen, the team rarely moves at exactly one fixed velocity. 
If a situation like that does happen, it’s probably a good idea to touch base with team members regarding the agreements on updating the burndown chart and to discuss any concerns, fears or misunderstandings they might have.
 
 
 
  • Envisioned dysfunction — At the very beginning of the Sprint, the team has a relatively low velocity, but it increases over time and eventually the team manages to consistently complete the forecast in estimated boundaries. Situations like that are common for new teams that need some time for self-organization. 
Another common circumstance that may cause the same effect is the change/flow of team members, which results in short-term productivity reduction (J-curve). In these situations, the first thing the team needs is time for self-organization.
 
 
  • Commitment difficulties — Sometimes a team realizes the work selected for the Sprint is too stringent, and they cannot complete their forecast. This might happen during the first couple of Sprints when the team is still learning to work together and build out the definition of done. 
In this case, they might remove product backlog items from a particular Sprint in order to meet their goal, which results in a significant drop on the burndown chart. Cases like this should be discussed with the product owner and should be more of an exception than a repetitive occurrence.
 
 
  • Exceeded commitments — Some burndown charts use estimation logic. That means team members should estimate the tasks they’re going to complete. It’s not uncommon that they may overestimate the difficulty of some tasks and not realize it until they start work on those tasks. 
In that case, team velocity increases dramatically, and the team might decide to add more tasks to the current Sprint. This is a common activity that artificially increases the velocity of the team since initial task difficulty isn’t being re-estimated. 
 
Another situation that causes the same effect is when the team finds a new technique or solution to complete the task, which improves their velocity as well. On a burndown chart, this will be represented as a sharp increase of the actual remaining points line.
 
 
  • Scope creep — This happens to the best of us. As the team progresses, they might need to add more work to the Sprint. That might happen for many reasons, such as product backlog items not being properly refined, wrong technology being used or new dependencies being identified. 
 
As a result, the team completes some part of the work, but it’s not clearly visible on the burndown chart since the team constantly needs to add more work (new findings). In these cases, the team is likely not to be able to achieve the Sprint goal and might decide to terminate it early.
 
 
  • Delayed report — When the team isn’t very familiar with burndown charts and/or doesn’t update them regularly, they can face delayed report issues. This results in a step-looking diagram, which is updated when the team completes a big part of work, ignoring small activities that are being completed on a regular basis.
  
 
If you observe any of these trends, it’s good practice to talk to the team during the retrospective and teach/coach them on how to use the tool correctly. Moreover, it would be very helpful to communicate the necessity of burndown charts and their advantages.
 
All in all, burndown charts are useful tools that motivate team members at a subconscious level, provide good visualization for task tracking and decision-making activities, and allow the team to identify impediments early. 
 
A burndown chart should be created for the team and used by the team, while taking into consideration the disposure of the chart to stakeholders, Scrum Masters, product owners, etc.

Is this answer helpful?