How burndown charts are defined?

Burndown chart is a way of visually measuring a team’s progress on a daily basis to keep a project on track in order to achieve the required goal. The amount of work remaining in a project is then visible to all the team members and management. If there is any unexpected deviation from the estimated plan with respect to time or work completion, the team can respond quickly and deliver the expected product within the desired schedule.

The goal is to hit the ground by moving downwards after every iteration, starting from the position of total work to be done at the top. The amount of work left during the start of a project is the sum of all the story points (sum of points of all user requirements) and becomes 0 when it reaches the target end date of the project.

It can be plotted by using either story points or task count on the vertical axis. The most effective way of using burndown charts is plotting it by using effort remaining versus time. Firstly, teams need to break down the tasks with a limited number of hours and then, plot an ideal burndown chart that can represent the expected scenario to complete the task. Any deviation from the ideal line shows the speed of progress whether it is going slow or fast.

Burndown chart – representing ideal scenario with estimated hours left (in red) and actual scenario with actual hours left (in blue)

Reasons for using Burndown Charts

The use of burndown Chart in a project is intended to keep an eye on all of the simultaneous agile development methods going on within a Scrum team. For instance, if the burndown Chart shows that the team may not likely reach the sprint goal, then the team can take the necessary actions to stay on track.  

Also, to make sure that time and budget for the project remain fixed and just the scope varies for duration of the project, which otherwise is difficult to maintain in the traditional methodology projects.

Strengths and Weaknesses of Burndown Charts

Strengths

• It helps in monitoring the progress by showing project’s velocity in a simple and easily understandable way. Teams can visually compare actual velocity against the estimated velocity to meet the deadline.
• Teams can calculate actual progress of work done by providing real data that makes the reality of the project clear and warns early if the project starts going off track.
• Identifying problems at an early stage and highlighting corrective action plan can help the team gain more trust of the client.
• Burndown charts are verifiable, which eliminates the possibility of guessing around and let management decide the target end dates accurately.
• Including scope lines for every milestone can show the team and stakeholders the effects of varying scope clearly from one release to another.
• Visibility of progress line moving closer to the target can encourage and motivate the team members to keep performing with the same pace from the start till the end.  
• Task priority and start/end dates can be easily changed in a project without affecting the chart, that significantly reduces the time spent on adjustments compared to other progress tracking methods.

Weakness

• Having an assumption that amount of work never change, leads to problem in many situations because actually the amount of work keeps changing. It might appear that the team is performing exceptionally or it can make the team appear sloppy.
• It shows misleading progress report when initial estimations are poorly made or scope keeps varying.
• If not updated accurately by team members on regular basis, it can result in displaying false progress.

How can you measure it effectively?

Creating burndown charts accurately are vital within any scrum project. Teams can either create these charts manually or on task boards, or use any software tool available.

There are various ways to use burndown charts effectively. Below is the GQM (Goal-Question-Metric) approach to measure its effectiveness.

• G: Avoid adding duplicate efforts
  • Q: How to distribute tasks which are common to more than one task?
    • M: Add task to only 1 user story to avoid the mislead project tracking

• G: Not to make tasks too big or detailed
  • Q: How many hours to include in every iteration that does not make tracking difficult?
    • M: Keep the task short and time-boxed. (limit to 10-14 hours)

• G: Control Scope to Ensure On-Time Delivery
  • Q1: What is the team’s velocity?
    • M: Story points completed per iteration
  • Q2: What is the release progress during a release?
    • M1: Total completed story points over time since start of the release.
    • M2: Total story points in the overall release over time since the start of the release
  • Q3: What is the predicted target end date?
    • M: Total remaining story points in backlog divided by velocity to show remaining number of iterations towards release completion

• G4: To avoid delays in the burndown chart progress
  • Q: How the team can ensure update burndown chart daily?
    • M1: Calculate effort spent and effort remaining among the team members
    • M2: Adding retrospective action items from previous items

Conclusion

There are varied ways in which burndown charts are being used. It can be plotted at sprint level or product release level. These show the progress of a team in a single line that is very easy to understand and does not require any detailed explanation.

However, it can be misleading if not plotted properly and these charts can display incorrect information. So, it is imperative that these should be read and understood clearly and correctly before important decisions are taken for any project.

References for this article are: www.scrumalliance.org,www.agilenutshell.com.