How to get this most out of a Burn down Chart

Many scrum teams focus mainly on the user stories within a sprint and fail to recognize the impact a Burn-down 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 Burn-down Chart shows the amount of work that has been completed in a sprint, and the total work remaining. A Burn-down 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 Burn-down 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 under performance. 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 but takes a specific point to move 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, therefore, 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 misinterpretation of the client’s initial needs and prioritization.
• Features that were initially completed got rejected or there are showstoppers defects that the team needs to change focus to make a priority to.
• Scrum team adds User Story to the sprint because they completed the work items ahead of the Sprint target date; Good Spikes!

Flatline Patterns:

Having a flatline typically stems from not having any progress within a specific period of a sprint. There are a few flatlines that are accounted for such as non-working days; weekends for the average scrum team, public holidays, and company sessions. The experienced Project Managers account for these known flatline periods during Sprint Planning to reduce the team capacity, therefore, 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 to use to bring these issues up for both 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. This is a high-level summary of the overall sprint which allows the client to get a sense of what happened during the sprint and if there is anything to call out it’s done there and then it allows for the team to be completely transparent around their performance and achievement. This is then followed up by a breakdown of each user story within a table and the status and if needed a 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.