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.
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.
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.
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.
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.
3. Create your VMs. We’ll be creating three VMs (one manager and two worker nodes).
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.
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.
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.