PMs guide to tricky questions: What burndown can tell you?

Show me your burndown chart and I will tell you how the things are going. To be honest I am amazed how simple the things became for the project managers (does not depend whose hat PM is wearing now – scrum master, product owner) now – you need only a few metrics to be able to plan and forecast with the same success rate as it was previously. The burndown (I personally prefer burnup) chart is a very simple thing – easy to explain, easy to maintain. But it is a powerful instrument in the hands of the scrum master and the team.

I often hear from my colleagues that all these burndowns and velocity tracking are useless. They seem to be smart people, so instead of saying that they are probably idiots I tried to find out why it is not working for them? I found out some interesting things, so here are my simple recommendations how to make the burndown work for you:

• We all know how the ideal burndown should look like. There is some chance your sprint chart will be the same, but it is very low. So when you see smth like that – you should be really scared. I am no joking! Do not turn back! The will kill you if they understand you uncovered their trick! ^-^ I think, it is obvious that the team is not too honest. They are “adjusting” the progress to have the good looking chart. So rule number 1 is: be honest. Are you working for the chart to be ideal? Why are you moving these “almost done” stories to “done” column? You, yes, you! I know that you are doing that!
• Carefully store the history. Think of this as the complex dynamic system – how can you even try to predict something is you have no data? There is a chance you can be closer to the accurate predictions only after some period of time you are in the development process with this team, not earlier than 5-7 sprints, when the team starts to be more confident. So store all the previous data, analyze, how the metrics change, hope that it change in response to your actions, experiment. I always feel as this is my biggest treasure in the project (after the team itself, of course).

• Update the progress often, do not do that on the last day of the sprint. As it can be just too late 🙂
• Bring the burndown chart and other metrics diagrams to the retrospective meeting. Do not just leave them in Jira, so no one except the Scrum master looks at.

What the burndown can tell you

The chart can help your team to find out the following information:

• How well the things are going: how is the progress?
• How close is the team to being self-organized?
• How good we are with estimating and planning the sprints?

As a result we can understand what can be improved.

Lets discuss the different variations of burndowns your team can have:

New waterfall

The most common situation I have seen. There is a long plato with no progress and then the team closes almost all the stories. I named it “new waterfall”, because one of the reasons is that the team goes through the development of all the stories and then moves them to QA instead of working on them story by story. Typical situation is the following: team even discusses that “we will code for 7 days and then will have 3 days testing”. Sounds familiar?

The other reason can be the large size of the story/stories. So there is no progress until this huge task is done.

Once I saw this kind of burndown in the team that realized they could not succeed with doing the tasks they planned for this sprint, so they just moved almost all the tasks to the next one. So they just changed the scope and the turndown is not showing you the changes in sprint backlog. Smart bastards)

There is no end

The chart goes the opposite direction. There are several reasons:

• It is the first sprint and there is still chaos
• User stories are re-estimated during the sprint
• User stories are constantly added to the sprint

Team is dead

It can be ok for the first sprint. But what if that is in middle of the development? There can be some reasons apart from the death of all the team members:

• Definition of done is not working with the latest changes of the environment. You need to update it.
• You are not removing the obstacles appearing on your way.
• Stories are added to the sprint – the exact work amount as is done by the team. So no progress is visible.
• Product owner having vacations – no one cares about the backlog anymore)
• Team is not tracking progress.

To good to be true

Seems that they are overperforming! But let’s not to be too exited, there are still some issues:

• Team committed to less than they are able to complete. It is ok. But did they do the same the previous time? Are they afraid not to cope with the commitment? Are they tired after a release marathon and want to have a relax mode for a while?
• Team just didn’t have stories to work on, so the issue is on the PO’s side.
• Over-estimation of the stories complexity.

Great team

Such progress might be observed on charts of experienced teams. The team has completed work on time and met the sprint goal. You can relax a bit if the team has this kind of charts for the several sprints in a row.

Almost there

This is a common situation too – almost all the user stories are completed. The obvious possible causes are the underestimated complexity, too optimistic planning and adding the stories during the sprint.

Team is expected to plan the next time according to the velocity they achieved in the previous sprints. What keeps surprising me is the situation when team commits to more than they can accomplish again and again. Their PM even explained to me “They will relax if we plan less, I should keep them alert!” But what is the point if they never accomplish what they commit to?

Possible improvements for your burndown

All the improvements are based on adding more data to your burndown, so you can make your predictions and analysis easier:

• Adding the “scope” line to the burndown, so you’ll get more data on the diagram to be able to understand the situation better. Now you see if the stories were added to the sprint backlog during the sprint.
• Adding the impedimnets/blockers information to the burndown, so you can see how the progress is dependent on them.
• Adding any important for your team information, like the dependencies from other teams, releases of other modules of your product, etc. Just discuss that with your team during the retrospective.