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

burndown copy

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

burndown copy 8

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

burndown copy 9

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

burndown copy 2

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

burndown copy 3

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

burndown copy 4

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

burndown copy 5

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

burndown copy 6

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

burndown copy 7

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.

anti1

9 thoughts on “PMs guide to tricky questions: What burndown can tell you?

  1. Galina – great post, thanks for taking the time to write this up so thoughtfully. Throughout your posts you often reference indirectly really listening to people and hearing what they are saying, as well as listening for what they are not saying (e.g.: why some people may feel burn down charts are ineffective). While you work in software development and reference some tools that are specific to software development processes (Jira), the methodologies that apply to all projects are the same regardless if you are building software, bridges, homes or process improvements. The tools may vary from one industry to the next, but I challenge all Project Managers to look beyond the specific tools you sometimes reference and apply the concepts you teach in their area of Project Management!

    1. Thank you for your comment) My goal now is to be a good listener. 5 years ago I was trying to fix anything I thought to be incorrect immediately) Agile is great, so everyone should implement Agile! 🙂 But now I understand that the perfect answer to any issue case is “It depends…” And the only always working tool is your brains.

  2. Nicely stated! I’m personally not hard on my team in the “Almost there” style burndown. To me, as long as they are generally parallel to the line they are getting work done at the required rate but likely underestimated some effort. It’s not perfect but it’s not bad either.

    1. Yes, it is one of the “positive” cases. I try to encourage them to commit to less number of story points next time, so we finally can complete the sprint goal and feel relief. It is hard to be “almost done” for a long time- team can be frustrated or just “give up”, not taking seriously any commitments.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s