What is the Release Burndown Chart and how is it used in Scrum Projects? In an earlier post, we went over the value of the Minimum Viable Product (MVP) in enhancing Product shipment. This was discussed both from the Pre-Project viewpoint and for the Management of the Product Backlog. There are numerous tools and techniques that can be utilized throughout Development that will keep the Scrum Team focussed and on track. These tools include the Scrum Ceremonies such as the Sprint Retrospective.

This post takes a look at one of the tools you can use in handling Sprints, the Burndown Chart. Reliable usage of the Burndown chart will enable the Scrum Team (Scrum Master, Product Owner – the Voice of the Customer, and Development Team) to:-.

• Put a stake in the ground on a daily basis regarding Sprint development.
• Anticipating potential Risks of Project success or failure.
• Improve future selection of Work for the next Sprints.
• Gauge the rate of ad-hoc Changes and Scope Change to a Project, and how it is affecting completion.
• Notify Stakeholders of exactly where a Sprint remains in one glance.

There are 2 types of Burndown Chart. The Sprint Burndown is utilized daily during the Sprint. The Release Burndown Chart is updated at the end of a Sprint. Neither chart is complex and can be produced in Excel if you do not have an Agile Management tool. Tools such as Jira can automate the process.

While the X-axis on the chart is constantly Duration (variety of days to total), the vertical axis can be based either on remaining Effort (in hours) or on Story Points finished. There are benefits and downsides to both options, which we will talk about later.

Release Burndown Chart: Story Points or Hours of Effort?

You will remember that when we discussed the MVP, we recommended limiting MVP analysis to Epics and Features, and not User Stories. Story Points add another level of granularity for Assessing Scrum Project progress.

Hours of Effort can be used initially as the yardstick for Burndown Charts. However, more recently there has been a move towards using Story Points. This is because hours of Effort are not a common measure for the experienced Developer and the beginner. A beginner may take twice the time to Develop a User Story than an experienced Developer would do. So they will rather debate the level of difficulty of the Story. They are then more likely to reach an agreement on the level of difficulty for the User Story. The fact that the new developer will take twice as long is no longer the yardstick. The Story point “medium” is the new measure. The Scrum Team can Work with the number of outstanding Story Points and Story Complexity to decide who does the Work. One rule to observe is that Story Points can only be added to the graph for completed Stories. It does not help to add points of Stories that are not completed. This distorts the true view of Sprint progress.

Release Burndown Chart: Calculating Story Points.

If you currently use Story Points, you will be familiar with one or all of the approaches below. If not, please note that there is no common Value for calculating Story Points. It depends on your Environment. Here are 3 options that can be used. The method is not important, the fact that all team members settle on the level of Complexity is what matters.

T-Shirt technique:- XS, S, M, L, XL, XXL – this is a great and fast technique of Estimation.

Power of 2 – for those who like binary – 2,4,8,16,32,…

Fibonacci sequencing – Named after a medieval Italian Mathematician, the series is based on including the 2 last numbers in the series to obtain the next number.
e.g. 0,1,1,2,3,5,8,13,21,34…

The accuracy of the Story Points assigned to a particular Story is an approximation. You do not have to be too precise. There will be over and under-Estimation for each Story in a Sprint and in the Product Backlog.

Utilizing a Burndown Bar Graph.

The Burndown line graph is a great basic guide of progress and present state. The bar chart is an excellent choice when producing a Release Burndown. There should be no Changes (there “must” be no Changes for a successful Project and Sprint) in Scope during a Sprint. Using a bar chart for Release Burndown Charts shows the effect of Change.

Changes are added to the Project between Sprints.

We found these books great for finding out more information on Agile Scrum:

Making Effective use of The Burndown Chart.

The Burndown chart can be problematic if it is not fully understood. This is specifically the case for the Scrum Master. The aim is not to attain a Project development that designs the “ideal” line. The aim is to use deviations above and below the line for modifying Estimation. These modifications can be made to both the current and subsequent Sprints.

The Sprint Burndown chart must be updated daily. It should be used as the input for the daily Stand-Up Meeting. It is a lot quicker to see development on the chart than listen to explanations. The 15 minutes of the Meeting are both much better used in this way. Additionally the visual can be left up for others to get an up-to-date view of development.

When a Project begins, Project Estimation has a lower Confidence level. This is because of all of the unknowns in the Project. As each Sprint is finished, with the aid of the Burndown Chart, Estimation will improve.

The Release Burndown chart, when showing the effect of applying Changes mid-Project is a Valuable tool in explaining to Stakeholders why Changes can impact a Project and how long in particular they are delaying this Project.

While there are other tools and techniques to use, the simpleness and effectiveness of the Burndown Chart makes it the perfect Agile tool.