How to get this most out of a Burndown Chart

Many scrum teams focus mainly on the user stories within a sprint and fail to recognize the impact a Burndown Chart can have on team performance.  In this article, we will deep dive into the elements that make up a Burndown Chart and look at the useful insights it can provide the team.

Prerequisite:

• The scrum team needs a Project Software tool: Jira, Rally Azure DevOps
• The scrum team needs to be familiar with the basics of scrum (specifically know how to estimate and use KanBan board)

A Burndown Chart shows the amount of work that has been completed in a sprint, and the total work remaining. A Burndown Chart is used to predict your team's likelihood of completing their work in the time available. They're also great for keeping the team aware of any scope creep that occurs.

Understanding the Sprint Burndown Chart:

Elements (1)-(3) identified in the chart are elementary to achieving a sprint goal. 

1. Estimation Statistics: The vertical axis represents the estimation story points that the team selected for the sprint.  E.g. Total Story points [45]
2. Remaining value: This red line represent the team performance on the number of story point completed and the amount remaining in the sprint
3. Guideline: The grey line shows an approximation of where the team should be assuming linear progress.

The scrum team gets a clear understanding of how the team is performing against a linear progress guideline, which helps them know the likelihood of achieving the sprint goal. If the red line is below this line, congratulations - your team's on track to complete all their work by the end of the sprint. Though this isn't foolproof, it's another piece of information to use while monitoring team progress.

Analyzing Remaining Value vs Guideline

Above the guideline:

It represents the team's underperformance. Therefore, decreasing the likelihood that the team will meet the target at the end of the sprint. There are several factors that can contribute to the team's consistent burn rate above the guideline. They include; the sprint grooming session inadequate, the team needs additional support to reduce bottlenecks, etc. 

Below the guideline:

This represents a positive for the team, the team is outperforming the linear progression, therefore, ensuring a higher probability of hitting the target for the Sprint. Depending on how quickly the team completes the work item can also take on additional stories to the sprint. However, if this is a consistent thing across a number of sprints, therefore, indicates the team either overestimating the stories (creating buffers) or they are not adding enough stories into the sprint. This may show the sprint’s performance high but it also affected the overall project performance of being drawn out.

Sharp decline:

It is typical to see a particular sprint toggle between the two states mentioned above. The Sharpe decline, on the other hand, often speaks to how the team views the scrum. If the team is not actively updating the board and at a specific point moves all the changes, the burndown chart will show a significant drop. This is a pattern that does not help the team track their performance. Another reason for the sharp decline is the team underestimates stories that should be more complex than the team initially stated, and the team spends a long time trying to resolve them.

How to identify unexpected issues:

There are two main patterns on the Burndown Chart that teams need to identify and respond to quickly during any particular sprint.

Spikes Patterns:

A spike represents an increase in the number of story points within the sprint. Therefore if the team capacity remains the same this can then affect the team’s ability to meet their target. There are a number of factors that contribute to spikes within a Burndown chart that can cause an issue with the team performance.  

Here is a list of events that causes spikes:

• Re-estimated a User Story- after a sprint starts, if the team identifies that a specific story is more complex than what was initially estimated they would need to increase the story points to reflect the complexity. 
• Product Owner/ Client adding additional User Story inside the Sprint- this can be due to shifting priorities based on external environmental changes (Market needs increase, etc) or the scrum team’s misinterpretation of the client’s initial needs and prioritization.
• Rejection and Showstopper Defects- features that were initially completed got rejected or there are showstoppers defects that the team needs to change focus to make a priority to.
• Good Spikes!- scrum team adds User Story to the sprint because they completed the work items ahead of the Sprint target date.

Flatline Patterns:

Having a flatline typically stems from not having any progress within a specific period of a sprint. Non-working days such as weekends for the average scrum team, public holidays, and company sessions are a few flatlines accounted for. The experienced Project Managers account for these known flatline periods during Sprint Planning to reduce the team capacity, further impacting the number of Story points that the team can take on during that particular sprint. 

However, there are other flat lines to consider which are unplanned events such as:

• Technical Roadblocks [Server, Environments, etc going down]
• Team working on a User Story that creates an impediment preventing the team to progress
• The team having external distractions causing their work performance to suffer

Although these are unexpected events it’s always important to be very reactive and responsive to find solutions for the team to get past these. Also, the Sprint Retrospective is another session used to review Spikes and Flatline patterns for the team to look at ways to improve on the next sprints to come.

Sprint Final Report using a Burndown Chart:

Looking at the Sprint Final Report used during the Sprint Review session at the end of the Sprint benefits both client and scrum team. It is a high-level summary of the overall sprint.  It allows the client to get a sense of what happened during the sprint. If there is anything to address, it's done there and then allowing the team to be completely transparent around their performance and achievement. A follow-up is done by breaking down each user story within a table and the status and an optional comment. Afterwhich a demo of the features completed is done for the client to provide feedback and accept and/ or reject the user story completed.