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!
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.
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.
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.
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.
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.