Burndown charts are a popular tool used in Agile and Scrum. And there is no doubt about it. They're giving a clear understanding of progress on release in real-time and are great for tracking remaining time or effort required to deliver release. In other words, you'll be able to see if your release is on track, ahead or behind simply by checking this chart.
How is release burndown chart calculated?
Alright, so the release burndown chart helps with tracking the remaining work overtime. But how the chart actually looks 🤔?
Vertical axes of the chart represent remaining work, and horizontal axes represent the time.
The Ideal burn rate is a linear interpolation of maximum work planned on the first day and zero work remaining on the last day of the release.
The Actual burn rate is a real representation of release progress over time.
To represent remaining work you can use:
- Number of issues assigned to release,
- Aggregated number of Story points,
- Estimated time,
- Other metrics that your team uses to estimate work.
It's also often useful to convert numbers to percentage to eliminate distractions and make the chart more understandable. You can calculate the Percentage of remaining work like this:
Let's prepare data for the chart. Use the formula above and calculate the percentage of remaining work for each day and simply plot this data on the chart.
How to read burndown chart
You can use burndown chart as the indicator if your release is on track or there is a risk of being behind that can lead to potential slippage.
If you spot the Actual burn rate line being mostly above the Ideal burn rate, it highlights there might be potential challenges, and you should investigate what the problem might be.
However, if this happens in the initial few days there might not be a big reason to panic. If deliverables are bigger and take several days to deliver you will see the line dropping bit later and there might be a bigger drop at once. With this in mind, that's also why it's important to split the big tasks into smaller parts that take one day or less to deliver so you can try that next time.
On the other hand, if the Actual burn rate appears to be under the Ideal burn rate line, you're ahead of your schedule!
A third scenario, which happens rarely, is for your Actual burn rate to match with the Ideal one. The team is working on the items every day, but on the chart, you'll see the drop only once the item is done. The Ideal burn rate should be only informative.
How to create Release burndown chart in Jira
There is usually a question who should prepare these burndown charts. Is it Scrum Master, Product Owner, Project or Release manager? Ultimately these people and their stakeholders are the ones interested but none want to spend time manually creating these in spreadsheets.
Luckily enough if your team works with Jira, you can generate these Release burndown charts, and they'll update automatically when the tasks are done.
Burndown chart in Jira Scrum projects
Scrum projects (the ones where you can run Sprints) have Release burndown chart option available out of the box.
You can find it in Project menu > Reports > Burndown chart.
The chart gives shows you Completed and remaining work based on Story points grouped by sprints on the horizontal axes that represents time.
Burndown chart for Jira Kanban projects and cross-project releases
Kanban projects in Jira are lacking Release burndown functionality out of the box. To get the chart here use Jira plugin, in this example we use Swanly - Release Management for Jira.
Here you can access the Release burndown chart from Release detail > Burndown tab.
The chart gives 3 option for tracking progress: Count of issues, Story points and Original time estimate. On horizontal time axes, it then shows dates and Release date is highlighted.
In the end, project management and development are complex. There are challenges coming up every day. In order to get a clear understanding of current release status, you need to have access to real-time information. Creating a release burndown chart in the issue tracking systems your teams use on daily bases gives you exactly this view.