From the Boss to Project Members, How to Gain Insight into Team Work from the Burndown Chart?

I. What is a Burndown Chart?

The Burndown Chart is a visual representation of the remaining workload over time. Typically, the workload is displayed on the vertical axis and the time on the horizontal axis. This chart is particularly useful in predicting when the work will be completed, making it valuable in agile software development, such as Scrum. Burndown charts can be used in both Sprints and Epics.

Burndown charts clearly show how much work has been completed and how much remains in each period. We can use this information to predict the likelihood of completing the work in the remaining time and plan for current and future sprints. To ensure the successful use of the chart, all project members need to understand its purpose. For example：

Image Source: Agilenutshell

• Horizontal axis: Shows the number of working days (The star point is the time of day. General value points are calculated daily.)
• Vertical axis: Display remaining work (production value, at the time of each sprint planning meeting, the team should estimate the value of each story, 160 in the example above is the sum of the value of all stories.)
• Planned work remaining curve: The curve is a straight line.
• Actual Remaining Work Curve: This curve is affected by the actual work efficiency of the team, floating above and below the planned curve.

So, from this table we can see:

• How much work has been done?
• How much work needs to be done?
• How much valuable work do you do every day?
• Is the current work speed keeping up with the plan?
• ...

II. How to Look at the Sprint Burndown Chart?

When analyzing a sprint burndown chart, it's essential to remember that the chart may not follow the plan precisely. In reality, unexpected changes may arise, such as new requirements, time constraints, or team efficiency issues.

Image Source: Agilenutshell

Let's look at several real-life examples to gain a deeper understanding of the burndown chart. Dusan Kocurek has provided insightful analysis, as shown in the chart above. However, it's crucial to note that each project's story is different and requires individual analysis.

Despite this, several common themes emerge when examining the burndown chart. For instance, tracking the actual remaining work curve and comparing it with the planned work remaining curve is critical. This comparison can help you identify whether the team is on track to meet its objectives and adjust your plan accordingly.

Ultimately, the burndown chart provides an essential tool for monitoring project progress and ensuring you deliver high-quality results on time. By carefully analyzing the burndown chart, you can identify potential issues early on and take proactive measures to address them.

1. Burndown Chart of Excellent Team

Excellent team：

This burndown chart shows that the team can organize its work.The product manager understands the workload of the iteration, and the Scrum master can help the team complete the task. The team is not overloaded and is working on iterations on time. The team can correctly estimate its capabilities; no corrections are required during iterations.

Not bad team:

This is a typical work progress burndown chart, seen in the work of many experienced agile teams. The burndown chart shows how the team can meet deadlines, adjust to accommodate backlog tasks in iterations, and work extra hard to get things done. The team must be self-reflective and immediately discuss how to change the plan when it sees progress slowing down early in the iteration.

2. Team Burndown Charts that Need to be Adjusted

“Too fast” team work burndown chart:

The burndown chart shows that the team completed tasks much earlier than expected. Then they may be ignorant of their powers. The team completes the requirement and doesn't move on to other tasks, even though the team has the time and energy to do so. In this case, the requirements may have been overestimated, so the team completed the task ahead of schedule. The team's work velocity is not properly estimated.

“Too slow” team work burndown chart:

This burndown chart clearly says: "You didn't get the job done." This team is late throughout the iteration process and fails to adjust work reasonably. The burndown chart also shows that the team did not complete the requirements, which should be further broken down, or moved to the next iteration.

3. Burndown Chart of Novice Team

“The management is coming” team work burndown chart:

Such teams may not be updating themselves on their work progress. One situation here may be that the product manager adds some work that has already been done, so the burndown chart timing work curve is a straight line. For example: suddenly, there is a slippery slope at work. Theoretically, the story is not divided, or the estimation is inaccurate.

“Heaven” team work burndown chart:

The first iteration of the team is generally this kind of burndown chart. This situation is the mother of success, and it is clear that the team is not up to the task. Every day, requirements or tasks are added to the iteration work, but no quarter of the work is recorded. Another reason might be that tasks in iterations are constantly being re-estimated.

III. If I am the Boss and a Little Uncomfortable Seeing the Burndown Chart for the First Time.

Teams that are trying agile development for the first time have a difficulty: how to make agile development and burndown charts more comfortable for bosses who do not know much about technology?

Because the burndown chart that the boss sees for the first time is almost not a burndown chart of an excellent team, but a burndown chart of a team that needs adjustment or a novice team.

At this time, their psychological reaction is:

• A sprint has passed, and KPI is not done...
• A sprint has passed, and KPI is not done...
• A sprint has passed, and the KPI is still not completed...

Please be sure to tell the boss in advance, so that the boss has a mental preparation. The burndown chart is a reference for estimating how to produce more efficiently. Estimating this matter, it may take about five sprints before it starts to slowly approach. KPI that do not pass the estimation is of little significance. Because programmers with a little experience can easily control the direction of the whole burnout chart after a few sprint adaptation periods. In the team I used to work with, the programmers began to consciously control the value of the tasks they could do, closing one task per day after spending half the time on it. The burndown chart is shown in the figure below:

In the "too fast" team burndown chart and the "too slow" team burndown chart, it seems that the "too fast" team completed the task ahead of schedule. But it is also possible that the "too slow" team estimated too much value initially. Even if it produced more value than the former, the previously estimated task seemed incomplete. Therefore, the positioning of the burndown chart should not be used as a unique/core KPI. My personal experience is: as long as the output can be completed on time and the team's work arrangement is reasonable, you can focus on other indicators.

IV. How to Draw Sprint and Epic Burndown Charts?

In today’s era, we have to learn to use tools.

Let's take Jira as an example, which is full-featured and complicated, and its speed is not even in China.

1. Sprint burndown chart

• Determine measurement method: In Jira, the workload can be measured regarding story value and working hours.
• Estimate each task/Issue: The team often discusses and determines this step in the Backlog refinement meeting. For example, the value of a story is generally estimated using the Fibonacci sequence, 1, 2, 3, 5, 8... In Jira, we directly fill in the corresponding estimate position. The biggest challenge of the burndown chart is how to estimate it! (So here, we have to pay special attention to the estimation）

2. Generate a Burndown Chart

In Jira, we select the required Sprint, click reports, and we can easily generate a burndown chart.

3. Epic burndown chart

In addition, Jira can also generate Epic burndown charts:

• Epic menu
• Increased work: The dark blue block reflects the workload added to this Epic per Sprint. This example is measured in story value.
• Work Remaining: The light blue blocks indicate the amount of work remaining.
• Work done: The light green blocks represent the work done per Sprint.
• Project completion progress forecast: Based on the existing data, the report area will automatically estimate how many Sprints are needed to complete the project.

V. Is There any Other Way to Measure the Work of Agile Development Teams?

Agile development focuses on two metrics:

• Value
• Flow

Most of the metrics on the market revolve around these two.