Burndown Chart and What It Tells
A Burndown Chart is used to demonstrate the remaining work along with time. The workload is generally displayed on the vertical axis, and the time is generally displayed on the horizontal axis. It intuitively predicts when all work will be completed, and is often used in agile software development, such as Scrum. Burndown charts can also be used for any project with measurable progress changes over time.
The burndown chart above is a typical one and was made in ZenTao, a Scrum tool. It is the sum of the remaining hours of all tasks in the project. It is calculated every day to coordinate and the indicator lines are generated based on it.
A Burndown Chart has four important elements:
- Horizontal axis: working days
- Vertical axis: remaining work
- Planned remaining work: a straight line
- Actual remaining work: a line goes up and down around the ideal line
Interpretation of Burndown ChartsThe actual progress of each project is different, so is its burndown chart. A Burndown Chart reflects problems, so the team can find and adjust in time.
- If the actual line is below the ideal one, it indicates that the progress is smooth and it is very possible that the project will be completed on schedule;
- If the actual line is above the ideal one, it means that the project is relatively possible to be delayed. The team has to pay attention to the progress of the project, and the manager needs to consider what caused the delay.
The task was completed on time, the actual line revolved around the planned line, and there was little fluctuation. It shows that the estimation of the workload of the project is accurate, the team complete the delivery on time.
The project goes very well and healthy, so basically no improvement has to be done.
The plan was completed on time. The actual line takes off first and then descends, indicating that the early progress is slow, but later stage the team adjusted the progress according to the estimated delivery period to ensure timely delivery.
Due to the increased workload, or the inaccurate estimation of the hours, the progress was behind the schedule at first, and then the causes might be found and analyzed, so it has been improved. The team needs a more accurate estimation of the velocity.
The task was completed ahead of schedule. The actual line is always lower than the planned line, indicating that the plan is not well made and the size of tasks is too small, or the estimates are too big.
The team velocity is not accurately estimated. The task should be re-evaluated and the team, too. The team can do more tasks or some of the team can be sent to do other projects.
The project is not finished. The actual line did not fluctuate much in the early stage, and the team pushed forward the work as planned, but the progress became slow closing to the end. Tasks were not completed on the scheduled delivery date.
Due to the increased workload, the team obviously slows down the work. To find the reason for the increased scope, the team should talk to the product owner, and stop adding tasks to a started project.
The tasks were completed on time. The actual line steadily grows higher than the planned, indicating that the team is overloaded and the progress is slow. But still, the delivery is done on time.
It also shows that the team is experienced and strong. They can work under pressure or they might work overtime to complete the project.
It is direct and objective to know the progress of the project by reading a Burndown Chart. It is also an essential element of agile development. In ZenTao, a Burndown Chart can be automatically generated and updated daily.
Except for what is been mentioned above, there are other Burndown Chart interpretations. Leave a message and tell me what kind of Burndown Chart your team has.