Scrum Visualizations – Burndown Chart

The importance of scrum visualizations for agile teams is stated in the “Scrum Visualizations – Velocity Chart” tutorial. A burndown chart measures how much work (in story points) has been completed compared to the expected estimation.

There are two main types of burndown charts: Sprint and Release. Sprint burndown charts show the amount of work that is being tracked during the sprint. Agile teams should track the sprint burndown and review the progress during the sprint retrospective to see how they did in the sprint. Teams should monitor the release burndown chart to see how they track with regard to reaching milestones.

Release burndown charts show the amount of work that is being tracked for the release of a feature or product. This could span over many sprints until the release is completed. A release burndown chart measures at a longer time duration how much is completed over the release. It can also show how much feature creep (adding a ticket in the middle of a release) occurs within a release. These examples are illustrated below.

How to create a Burndown Chart

Although your agile tracking tool (like Jira, monday.com, Trello) should already be able to automatically create these sprint and release burndown charts, you can also manually make your own.

Let’s start with a sprint burndown chart. At the start of the sprint, start with the total story points in the sprint, and draw a straight line to the end of the sprint. This would be your tracker line. At the end of every day, you mark out how many story points have been completed during that day. Continue until the end of the sprint, and now you have a sprint burndown chart. A similar process for making a release burndown chart is used. The only difference is the longer timeframe.

Common problems identified with Sprint Burndown Chart

Here are some of the common patterns you can observe in a burndown chart that could indicate some issues in your sprint: Late acceptance, slow progress, feature creep, and early finish. For the examples that follow, we’ve used the sprint burndown chart.

Late Acceptance

This chart shows that many of the stories is marked as done late in the sprint. This could be based on the product owner being slow to clarify tasks, or perhaps stories that have not been broken down into small enough chunks. Some stories might have been backlogged and caused the progress to be accounted for near the end of the sprint.

What you should do: If this pattern happens regularly, you would need to investigate what is causing this as it is likely that the team will not reliably hit the sprint goal.

Slow Progress

This chart shows that the team has consistently been above the tracker line during the sprint, and the sprint goal wasn’t met. This could mean overly-ambitious sprint goal setting, lower team capacity than expected, or other external factors affecting the sprint.

What you should do: During the sprint retrospective, identify what was the cause, and re-adjust for subsequent sprints.

Scope Increase/Feature Creep

This chart shows that mid-sprint, there was an increase in the story points to be completed. This could be due to new urgent stories being added mid-sprint or tasks had their story points increased from poor estimation.

What you should do: It is the scrum master’s role to protect the sprint from outside change that would detract the team from committing the sprint. Poor estimation needs to be reflected in the retrospective.

Early Finish

The team completes the sprint goal much faster than expected before the end of the sprint and they aren’t committing to enough work. This could be overly conservative estimation from the team or accounting for ‘buffer time’ to work on technical debt.

What should you do: Recalibrate your estimation of stories for subsequent sprints. For buffer time, it is better to set up a hardening sprint that allows the team to work on technical debt that has accrued.

Best Practices of a Burndown Chart

As seen from the patterns above, it is most important to remove variability in time so there is a consistent cadence of velocity that can be met. At the end of the sprint, the team should always review the burndown chart and reevaluate if they overestimated or underestimated the time required to complete. As you get more sprints under your belt, the more consistent your burndown charts will look.

Resources

https://age-of-product.com/burn-down-charts/

https://www.atlassian.com/blog/jira-software/7-steps-to-a-beautiful-and-useful-agile-dashboard

https://www.atlassian.com/agile/project-management/metrics

Jonathan Kurniawan

About Jonathan Kurniawan

Hi! I'm Jonathan Kurniawan. I have 4 years of experience working as a software engineer at Dolby on various different products. I'm currently pursuing my MBA from Hult International Business School and received my Bachelor in Computer Science from University of New South Wales, Australia. I'm excited to share my knowledge at the Data School by Chartio.