Sprint Burndown Charts Gone Wrong
You can learn a lot about a team from their sprint burndown chart. If you know how to read it.
After years of coaching and leading agile teams I’ve found 6 common patterns that appear over and over again in sprint burndown charts when something is going wrong. Unfortunately, burndown charts are just too high level to tell you specifically what a team is doing. But they’ll point you in the right direction. Then you’ll know what questions to ask. And quite frankly, the most important thing you can do to help a self directed agile team grow, is to ask the right questions.
But before we start looking at problems, let’s make sure we understand the basics. What is a sprint burndown chart and what should a good one should look like?
In Scrum at the start of every sprint (normally 2–4 weeks) a team commits to complete a fixed scope of work. That fixed scope is made up of a list of tasks referred to as the Sprint Backlog. A burn down chart is a line chart showing the quantity of work remaining in the Sprint Backlog over time.
Every time a task is completed, the quantity of work remaining is lower and therefore the burndown line burns down. Ideally the last bit of work will be finished at the end of the sprint and the burndown will go to zero.
The perfect burndown chart is created by a team working with a perfectly smooth workflow.
A team with a perfect workflow moves smoothly from one task to the next. Every day they get exactly one day of work done. When they find a bottleneck they clear it. When one person get’s stuck, then rest of the team helps them. Everyone finishes work in progress before they start new work.
But in real life it doesn’t always work that way.
Software is complicated, teams are complicated and when a team builds software the complexity is multiplied.
The 6 most common problems
So now I’m going to go through each of the 6 most common problems that you’ll see in sprint burndown charts. I’ll explain what must have happened to the Sprint Backlog to produce the problem and the questions that I would ask the team to help them figure out what to do. The goal of asking questions is to give a team the opportunity to grow. The questions are perfect for team retrospectives. But you can also use them during the sprint when you see a problem developing.
If you see The Cliff, it means that at the last minute, everything suddenly either got done or it was pulled out of the Sprint Backlog.
- Did we take on too much work this sprint and only finish it with last minute heroics and an unsustainable crunch?
- Is there a bottleneck in our workflow? E.g. Did everything sit waiting for approval with one key stakeholder until the last minute?
- Did stories bounce back and forth across the board all sprint? E.g. were developers and testers playing kanban board ping-pong?
- Are people picking up too much new work instead of finishing what’s in progress? Will work in progress limits help?
- Are the user stories too coupled and can’t be finished independently?
- Are people forgetting to update the board until the end of the sprint?
- Did anything get taken out of the sprint at the last minute? Did we take on too much work and just remove it at the end of the sprint to make the burndown look good?
When you see The Lag, it means that none of the tasks started on the first day of the sprint are getting finished until part way through the sprint. It means that it’s probably taking too long for work to get work through your workflow.
This puts a lot of pressure on the team towards the end of the sprint to finish everything at once. If the problem gets really bad you may even find it’s impossible to finish work in the sprint that it starts in.
- Are the tasks too large? Do they need to be broken into smaller incremental steps?
- Do we need to improve our CI/CD to remove manual steps or speed up slow steps?
- Is our process too complex or have too many steps?
- Is there a bottleneck caused by a stakeholder or external dependency?
- Is our team full of members who are too specialised which leads to too many handovers and too much back and forth?
- Would it help to set work in progress limits?
When you see The Gap, it’s pretty simple, the team didn’t finish the work they said they could finish. Now with this situation, please be a little careful. If you have a good self-directed team, they probably feel terrible about not finishing their work. So you have to be careful to ask questions without making them feel criticised. Try to be positive about the work they did do, reassure them that the goal is not to blame anyone, but to find ways for the team to improve.
- Did we just aim too high? Did we bite off more than we could chew?
- Did we underestimate how difficult the work would be?
- Did something unexpected happen? Either losing a team member or discovering an unexpected technical issue?
- Are we starting too many tasks and not finishing them? Did we finish the sprint with a bunch of half done work? Would work in progress limits help identify and manage the workflow issue?
- Did stories bounce back and forth across the board all sprint and never quite get finished? Is our workflow process too complex?
When you see The Wave you know that your team got a lot of work done, but unfortunately it wasn’t the work they said they would do. In fact, if the wave is horizontal, the amount of work done was perfectly counterbalanced by new work entering the sprint backlog.
I’ve found this situation to be surprisingly common. It’s particularly surprising because to do it a team has to have a culture of regularly and consistently violating one of the few hard rules of Scrum.
- Is Scrum right for us? If it’s genuinely impossible to forecast our work a sprint in advance, then Scrum isn’t the best way of managing our work and maybe we should just use Kanban?
- Does the team need training in how Scrum works?
- Are we being too nice and not setting boundaries with our stakeholders?
- Are stakeholders going directly to their ‘favourite’ developer and bypassing the team process?
- Are we being overwhelmed by unpredictable support work? If so, do we need to split or restructure our team?
When you see The Flatline it means that one task got stuck and never got finished.
In real life, sometimes things just don’t get finished and it’s not worth getting too upset about it. Remember, the end of the sprint isn’t real, it’s just a made up deadline. But, it might be worth trying to figure out what specifically about the stuck task caused the issue. There may be an opportunity to discover an area for the team to improve. Particularly if there was only one stuck task.
Just be careful to make sure that the person or people who were working on it don’t feel criticised. The goal is to find ways for the team to collectively improve, not to single out and punish one person for not finishing something.
- What caused the work to get stuck? Was it a technical issue? A lack of experience?
- If it was too much work, could more people have helped?
- Did we get the estimate wrong?
- Was there an external dependency?
- Could we have broken up the stuck task into several smaller tasks and at least finished part of it?
- Could we have split out a technical spike or prototype task to reduce technical risk?
When you see The Bounce, it means that the team finished most of their work early and then pulled new work into the sprint which never got finished. This can also obscure the fact that some of the original Sprint Backlog work may never have been finished.
- Are we working as a collection of individuals rather than a team? Is everyone starting new work rather than helping each other finish what is in progress?
- Did we aim too low? Should we take on more work next sprint?
- Why was something in the original Sprint Backlog stuck but other work could be finished. Why did one thing get stuck?
- Do we need to break down tasks so that we can only pull in work that we can finish?
- Should we use extra time at the end of the sprint for technical improvements and paying down technical debt?
I had a lot of fun writing this post and I hope you found it useful. I hope that learning to look for patterns in burndown charts helps you develop an intuition of team workflow and how to identify areas for improvements.
Just remember to keep things positive. Sprints aren’t real. They are imaginary deadlines teams make up to help them manage their workflow. So don’t criticise or punish people for not achieving made up goals. Instead, use it for what it was intended for, providing a simple empirical way of measuring and improving team workflow.
You’re doing a great job. 🙂