Smarter ideas worth writing about.

Scrum Team Mechanics: Burndown Chart

Tags: Scrum , Project Management

A burndown chart is a graphical representation of forecasted work completed over time. It was initially introduced by Ken Schwaber in 2000 and are extensively applied in Scrum agile development. The graph illustrates progress made towards 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 of 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 utilized for release trending/forecasting.

The structure of a burn downchart 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. It increases 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.). It is 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 arisen 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, involvement and improving collaboration. The simplicity of burndown charts makes it a perfect tool for a team’s self-effectiveness evaluation. Another important aspect of burndown charts is the motivational impact. Seeing the line creep ever closer to zero has a psychological effect on team members, motivating them to collaborate towards 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 is 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 do not show whether the team is working on the right product backlog items. Therefore, burndown charts are more 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 identify issues at an early stage and resolve them before they get worse. There are many trends which can be noticed in burndown charts, and we’ll cover six popular trends below: 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 of time is slightly less than estimated work. That means that 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 is probably a good idea to touch base with team members regarding the agreements on updating the burndown chart and discuss any concerns/fears/misunderstandings they might have.

  • Envisioned Dysfunction - At the very beginning of the print 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. Other common circumstances that may cause the same effect is the change/flow of team members, which results in short-term reduction in productivity (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 that 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 are going to complete. It is not rare that they overestimate the difficulty of some tasks and not realize it until they start working on them. In cases like that, 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 is not 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 because of many reasons, such as product backlog items were not properly refined, wrong technology was used, new dependencies were identified, etc. As a result, the team completes some part of the work, but it is not clearly visible on the burndown chart, since the team constantly needs to add more work (new findings). In cases like that 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 is not very familiar with burndown charts or simply not interested in updating it 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 any of those trends are seen, it is a 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 a very useful tool that motivates team members at a subconscious level, provides good visualization for task tracking and decision-making activities, and allows the team to identify impediments early. It 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.


About The Author

Project Services Consultant

Artsem is a Senior Consultant with Cardinal Solutions in Columbus, Ohio. He has broad experience working as a Business Analyst, Project Coordinator, and Scrum Master to successfully deliver projects of different complexity. His passion is educating organizations and teams about Scrum with the special emphasis on Scaling Practices. Artsem is also a certified PSM II, PSPO, SPS, PSD, ITIL, and Certified Kanban Coach.