Today, we’ll go through how to use Burndown charts to visualize and track your work progress.
It can help estimate whether your team is going to successfully meet your project deadlines and milestones.
What is a burndown chart?
A burndown chart is a line graph that displays the amount of remaining work in hours versus the time to complete it. As work is done, a line ‘burns down’ until it reaches zero: all work and tasks completed.
Burndown charts are useful to help us visualize the total amount of work required or remaining for a project and our rate of completing the work.
For example, in the chart above, we can see that the total amount of work at the start was 178 hours. And between 06/24 to 07/29, a significant amount of work was completed, cutting the remaining work to 40 hours.
Another example:
Looking at the chart below, we know that we are behind the estimated schedule, as the actual work burndown line (colored green) is above the estimated (orange) and ideal (grey) lines.
It’s also possible to calculate the difference in remaining work left, between our actual and estimated numbers on the current date. We are 4 story points behind schedule.
What is a story point?
A story point is a term that comes from agile software development where they refer to a product feature as a user story. In order to specify the amount of effort/work needed to complete each user story, a points system (i.e. story points) is used.
The number of story points is used to represent a number of hours or days required for a task. For example, one story point can represent 1 day or 8 hours, etc.
Absolute versus relative estimates
Burndown charts operate on the principle of estimating how much work is required for tasks. To figure this out, there are two methods used for estimation:
-
Absolute estimation is a direct estimation of the work/time required for a task, e.g. in units of man-hours, man-days, or man-months.
-
Relative estimation is an estimation of the work and time of a task by comparing it to another task. The unit for relative estimation in Agile/Scrum is a story point.
Why use relative estimation and story points?
Firstly, it’s easier to agree on an estimate of a task by using a common base for comparison.
For example, people tend to have differing opinions as to whether a task takes 5 or 8 man-days. Trying to settle the difference will occupy the team’s time and blocks everyone from moving forward.
However, it’s easier to agree that Task A is about the same size as Task B, and both should take about the same amount of time. Thus, the team can agree and advance on to work or other planning.
Secondly, it’s easier to update quotes later if we use relative estimates.
How? Let’s say we worked on Task A and it took 8 days instead of the planned 5 days. If we were using absolute estimates for our project tasks, we will need to readjust the estimates for the other tasks. For example, update Task B from 5 days to 8 days too, and so on for the rest of the other tasks. This will be quite tedious to do.
On the other hand, if we’re using relative estimates where both Task A and Task B are 1 story point each and Task A took 8 days (instead of 5), then it’s easier to conclude that Task B will also take 8 days.
Recalculating the time/effort for the rest of the tasks will be simpler to carry out and we can multiply the total story points by the new factor (8 days) to see if we can complete all tasks by the deadline.
Using relative estimates/story points with burndown charts in Backlog
Although each task/issue has an estimated hours input field, it’s entirely acceptable to enter the number of story points instead.
While using relative estimates or story points with your team members, it’s a best practice to discuss and decide on a reasonable amount of time it would take to finish a one-point task.
Then, team members can set their expectations in advance and the speed of their work rate is taken into account while planning the duration of the milestone or project.
Understanding the burndown chart
For example, if we estimate 2 days of work to complete a 1 story point task, then 5 tasks with a total of 5 story points would take 10 days. (If they are worked one after another, rather than at the same time.)
Displaying this on the burndown chart will look like this:
The estimated burndown line (colored orange) indicates a reduction in 1 story point every 2 days.
When work is done / a task is completed:
When a 1-point task is completed in 2 days as expected, the burndown chart shows a corresponding decrease in points for the actual line (green):
When work is delayed / task takes longer to complete:
However, if task A takes 4 days, which is more than estimated (and common in real-life scenarios) the burndown chart shows:
With task A taking more time, it has resulted in a following task to be behind schedule, hence the flame icon in the chart above.
Faced with tasks taking a longer time than expected, it’s standard practice for the team to find ways to lessen the margin of error by extending the deadline (postponing the estimated due date of the milestone) or reducing the scope of the sprint (moving some tasks to another later sprint).
If we were using relative estimates for tasks, we would not need to change the values for other tasks’ estimated hours. But if we were using absolute estimates and had entered the literal number of hours or days, we will face the problematic task of changing those numbers.
From this, we can see that relative estimates are more adaptable to change, more Agile! 
Conclusion
We’ve introduced how you can use relative estimates for burndown charts and how burndown charts can help you monitor your progress on milestones.
In a real-world project, tasks may be completed faster due to various factors, like the team’s experience. However, even in that case, it’d be best to see the actual results on the burndown chart before incorporating faster turnarounds into your work schedule.
I hope that this post is helpful for your work, please comment to let us know how you’re using Burndown charts in Backlog to organize and track your projects. 
Additional notes for Backlog burndown charts:
-
When an issue is assigned to a milestone, the issue’s start and due dates are used to calculate the plotting of the estimated line (orange) on the timeline. For example, if a task is due on 09/15, the estimated line should drop accordingly on that date for its estimated hours/points.
-
If the issue’s estimated hours input is left blank, the default number (1) is used to calculate the burndown chart.
-
Only ongoing milestones’ burndown charts are displayed. If the milestone is over (i.e. past its due date) or in the future (i.e. before its start date), its burndown chart is not displayed.
-
The chart is automatically updated every five minutes, or when a task status changes.