Burn Down Chart Examples - What Does Good Look Like?

Good vs. Problematic Examples - Using the Sprint Burn Down Chart as a Diagnosis Tool

What should a good burn down chart look like? Here are a couple of examples of good and bad.

The ideal: Following the ideal line

Perfect, your team is doing a great job sizing stories and working collaboratively in getting items to done throughout the whole sprint. If you’re the agile coach or Scrum master, go take a holiday ;-) Team, keep doing what you are doing. Also, please let the other teams in your organisation know how you are doing it!

A sprint burn down chart following the ideal line; sometimes slightly over, sometimes slightly under, but mostly fully aligned
The best burn down charts are the ones where the actual line always follows (or 'dances around') the ideal line

Unconfident: Drop at the beginning

There are definitely worse things than this burn down. All the work gets done. And not only that, it's even finished ahead of time! But if this pattern keeps repeating itself, it can point to inefficiencies and you're better off discussing it with your team.

A sprint burn down chart that drops quickly at the beginning; then stays below the ideal line for the rest of the sprint and hits zero five days before the end of the sprint
A drop at the beginning could point to an overestimation of your sprint backlog items

The team underestimated their capacity or overestimated some of the work. The first reason can easily be resolved by pulling in more work into the sprint backlog while the sprint is still going on.

Both issues should be addressed in the retrospective: Why did the team undercommit or overestimate? Is there perhaps a tendency for the team to receive additional work that doesn’t belong to the sprint and that’s why the team wants to keep its commitment for each sprint lower? This could point to a problem in your Scrum adoption.

Another reason could be a lot of technical unknowns that make the team overestimate most of the items to account for that uncertainty. You could try spiking some of the work one sprint in advance to reduce the number of technical unknowns.

Problematic Burn Down #1: Mostly horizontal, drop at the end

This burn down chart is a likely candidate for teams new to Scrum or the agile way of working. There might be a drop at the end or there might not be. In any case, it is clear that something is not quite right here. And if this happens repeatedly, you might have to explain yourself to management.

A sprint burn down chart with an actual line that is flat for most of the sprint; it suddenly drops at the end of the sprint, but never to zero
The very flat nature of the actual line makes it unlikely that the sprint goal can be achieved by the end of the sprint

There could be many possible causes for this:

  • The development team is not organised enough and doesn’t communicate properly; try refocusing the daily Scrum to the three questions: 1) What did I achieve yesterday towards the sprint goal? 2) What will I do today? 3) Are there any impediments preventing me from moving forward?

  • The development team doesn’t update their progress regularly. This makes the burn down chart unhelpful as a tool. Try highlighting the value of the burn down chart in the next retrospective and remind them to update their progress during the daily Scrum.

  • There is a bottleneck on reviewing pull requests or integrating work. Remind your developers to spend a part of each day reviewing each other’s code. Set up a CI pipeline that makes it easy to integrate new work and to spot problems.

  • The development team tends to start too many items at once and only finishes them at the end of the sprint. This again poses the danger of not reviewing ongoing work early enough and finding problems too late which can result in missing the sprint goal. Try introducing a work-in-progress (WIP) limit and limiting the number of items in your in development column to the number of members or pairs in the development teams.

  • QA or testing is not done within the development team, the testers don’t participate in the daily Scrum or in a different location which means that there is a delay in communicating with them

  • The product owner is not involved enough throughout the sprint, they only look at the items worked on at the end of the sprint and sign them off then. The danger here is that problems might be found too close to the end of the sprint, which means that those items cannot be signed off by the end of the sprint and the sprint goal can easily be missed.

  • The product has a lot of technical debt which slows down the development of new features. Try spending 10-20% of your upcoming sprints on fixing technical debt (or potentially spend a whole sprint cleaning up the code base).

  • There are a lot of dependencies to other teams that only get resolved at the end of the sprint (if you’re lucky). Was the Scrum master aware of the dependencies right from the beginning of the sprint and tried to resolve them (good) or was he only made aware at a later point (bad)? Try bringing in a mix of items with dependencies and without dependencies so that the team always has something to work on. Mention dependencies your definition of ready. Making other teams that you are dependent on aware early that you will need their help in getting x done in the upcoming sprint can also help. That way they can factor in the required time early.

Problematic Burn Down #2: Chart goes up during the sprint

This variation could point to a product owner gone rogue or a high amount of uncertainty or other changes in your work. Whatever the cause, burn down charts of this type can be very demotivating for a team: not only was the sprint goal missed, but it looks like you even travelled further away from it throughout the sprint.

A burn down chart with an actual line that goes up during the sprint; there are small drops here and there but overall the tendency is up rather than down
One of the most frustrating types of charts: the actual line does the opposite of what it’s supposed to do

Possible explanations for this type of chart could be:

  • Work is added after the sprint has started (scope creep). Your product owner needs to be more disciplined and stop adding work after the team has committed to a sprint backlog.

  • The work was not estimated well enough or necessary parts of work weren't discussed before providing the estimates, e.g. a prerequisite had to be added to get a story done. Try spending more time in refinement talking through the work necessary to get an item to done. Also, remind your team that during sprint planning they should not only commit to a number of sprint backlog items but also talk through how they plan to achieve the sprint goal.

Problematic Burn Down #3: Almost Finished...

This is a variation that I see too often, even in experienced teams. It shows that there is something going well but also that there are some unresolved issues that the team is struggling with.

A sprint burn down chart where the actual line continuously moves down, but always stays above the ideal line; at the end of the sprint, there is still scope left
How frustrating! The overall tendency is the right one, but the team just didn't move fast enough in that direction

Possible causes could be:

  • The team overcommits and the sprint goal is too ambitious. If this is a repeating pattern it might mean that the developers are afraid to speak up because nobody wants to be the first to admit 'weakness'. In sprint planning try asking 'can you think of anything that would make us fail to achieve the sprint goal?'. If the unrealistic workload comes up, get the team to commit to less.

  • Velocity drops because team members get sick or go on holiday. The sickness part is hard to plan for. Make sure though to check the holiday and training calendar in each sprint planning and adjust the sprint goal accordingly.

  • This actual line could also point to a mini-waterfall within your team. It might be the case that when the developers are done with an item, it takes 2-3 days until somebody starts testing it. This then naturally leads to the items that became ready to test last not to make it to done in time for the end of the sprint.

  • Another reason could be a bottleneck, such as a product owner who only signs off items once per week. This typically prevents the last items of a sprint from making it to done in time. Try speaking to your product owner and make it clear to them what this bottleneck means for your team morale.

Generate Burn Down Now