In an earlier article, we discussed the value of the Minimum Viable Product (MVP) in optimizing Product delivery. This was discussed both from the Pre-Project perspective and from Management of the Product Backlog. There are several tools and strategies that can be used throughout Development that will keep the Team focused and on track. These tools include the Agile Retrospective, which we go over in a different article.

This post takes a look at one of the other powerful tools you can utilize in handling Sprints in a Scrum Environment, the Burndown Chart. Effective usage of the Burndown chart will allow the Development Team to:-.

• Put a stake in the ground daily as to Sprint development.
• Anticipating possible 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 conclusion.
• Notify Stakeholders of exactly where a Sprint remains in one look.

There are two kinds of Burndown Chart:

• The Sprint Burndown, used daily during a Sprint

• The Release Burndown Chart, which 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 Duration (number of days to complete), the vertical axis can be based either on remaining Effort (in hours) or on Story Points finished. There are benefits and drawbacks to both choices, which we will go over later.

Story Points or Hours of Effort?

You may Remember when we discussed the MVP, we suggested restricting MVP analysis. This was to restrict analysis to Epics and Features, and not User Stories. Story Points include another level of granularity for Assessing Project progress. Lets consider a Burndown chart using Story Points.

Hours of Effort were initially utilized as the yardstick for Burndown Charts. More just recently the relocation has actually been to Story Points. The reason for this is that hours of Effort are not a common Measure for the knowledgeable Developer and the inexperienced developer.

An inexperienced developer may take twice the time to Develop a User Story that the skilled Developer would do. So they will rather debate the level of difficulty of the Story. This increases the likelihood that they reach an Agreement on the level of difficulty. The fact that the inexperienced developer will take twice as long is no longer the yardstick. The Story point “medium” is the measure. The Scrum Team can Work with the number of Remaining Story Points and specific Complexity to decide who does the Work. If the Sprint is ahead, possibly the medium problem Task can be selected by somebody less experienced.

One guideline to observe is that Story Points can just be contributed to the graph for completed Stories. It does not help to include points of Stories that are not finished. This distorts the real view of Sprint progress.

Diversion: Calculating Story Points.

If you already utilize Story Points, you will be familiar with one or all of the approaches listed below. If not, please note that there is no common Value for computing Story Points, it depends on your Environment.

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

Power of 2 – for those who like binary – 2,4,8,16,32,… Fibonacci sequencing – Named after a medieval Italian Mathematician. This is a sequence is based on adding the 2 last numbers in the sequence to derive 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 can be an approximation. You do not have to be too precise. There will be over and under-Estimation for each Story in a Sprint or in the Product Backlog.

Utilizing a Burndown Bar Graph.

The Burndown line graph is a good general guide of development and present state. Using a bar graph for Release Burndown Charts shows the impact of Change.

Changes are contributed to the Project in between Sprints and effect Completion.

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 troublesome if it is not totally understood. It must be understood by the entire Scrum Team (Scrum Master, Product Owner and Development Team). The aim is not to achieve a Project development that models the “ideal” line . The aim is to use discrepancies above and listed below the line for modifying Estimation, both in the existing and subsequent Sprints.

The Sprint Burndown chart ought to be updated daily. It should be used as the input for the daily Stand-Up Meeting. The chart is a lot quicker to see progress than listen to descriptions. The 15 minutes of the Meeting are both better utilized and the visual can be left up for others to get an up-to-date view of progress

When a Project starts, Project Estimation has a lower Confidence level element. This is due to the fact that there is a peak in the number of unknowns in the Agile Project at this stage. As each Sprint is completed, with the help of the Burndown Chart, Estimation will improve.

Release Burndown Chart

The Release Burndown chart, when revealing the effect of applying Changes mid-Project is a Valuable tool. It can be used to discuss with the Stakeholders why Changes can affect a Scrum Project and how long in particular they are delaying this Project.

While there are other tools and techniques to apply, the simplicity and effectiveness of the Burndown Chart makes it the ideal Agile tool.