4

In our Scrum there is a common phenomenon whereby the burndown chart does not represent well the team's progress. Most of the way into the sprint, only a third of the stories are closed, and the bulk of the remainder gets resolved in the past couple of days. This makes the burndown chart opaque, and not very useful for tracking sprint's success.

The main reason for this opacity is not team's unwillingness to close tasks, but rather the fact that we close stories only when they have been validated and demoed (as they should), and the validation process involves an unwieldy build installation/deployment which may take a few days from the point where the developer completed the code changes. The install/deploy cycle could be shortened, but the nature of the business we're in (network appliances) can never make it very fast.

I'd be interested in best ways to deal with this. The options I was thinking of were:

  1. Just ignore the burndown charts, and use other metrics to track progress.
  2. Separate coding and validation tasks into separate stories (obviously, not very clean, as the point of a story is to provide customer value). In other words, promote tasks into stories, and stories into mini-epics.

Is there anything better?

Improve this question
1
  • 1
    Your burndown chart is doing its job: it's telling you to fix the bottlenecks in your validation process.
    – Todd A. Jacobs ♦
    Commented Oct 23, 2016 at 5:10

2 Answers 2

Reset to default
4

Honestly, I'm not sure I'm seeing the problem. The primary purpose of a Scrum burndown chart is to measure and predict velocity, is it not? In which case, while the chart might not be pretty if most of the tasks are burned down in the last couple days, it's still going to be just as useful. As far as velocity planning in concerned, what happens day-to-day doesn't really matter - it's only the velocity for the full sprint that is important.

Regarding having the stories burn down before they're accepted, I would caution against it. What if the validation fails? Would the story get burned back up again? Now that would make the chart hard to read!

If, for whatever reason, you do need day-to-day updates of when initial, non-accepted development work on stories is done, then I would suggest using a separate chart. Don't throw away the burndown, though. Keep it for completed stories and velocity planning.

If you're just looking for a way to determine likelihood of reaching a Sprint's Goal, can't you just look at the sprint board? Assuming you have sufficient columns ('waiting for install/deploy' comes to mind, in your case), it should provide a decent overview of the sprint. If you're halfway through the sprint and 80% of your stories are still in 'TODO' or 'In Progress', then you've got a problem, etc. While it's not a precision metric, it should suffice in most cases.

Improve this answer
4
  • Thanks for the quick response - these are all valid points. However, assuming the burndown chart's role is to predict velocity, it fails in our case, since it often predicts low velocity/completion rate, while the sprints often turn out ok. I agree that option 2 in my list has many downsides, and I'm not a fan of it either. However, what tools then are available to predict sprint's velocity?
    – RomanK
    Commented Oct 23, 2016 at 1:04
  • @RomanK Updated my answer.
    – Sarov
    Commented Oct 23, 2016 at 3:26
  • Yes, sprint board is obviously an option that I'm using. I'll accept the answer, since it confirms my thinking that the burndown chart is not a very useful tool in our situation.
    – RomanK
    Commented Oct 23, 2016 at 5:26
  • Burn down charts aren't for predicting velocity. For velocity there is no need to track day by day, just take the aggregate values. My personal use of burn down charts Mid Sprint is to visualise progress and give an indication on the likelihood on completing the planned workload. That can allow proactive actions to improve the chances, and/or manage dependencies and business messages. If the majority of task complete late I a sprint, burn down charts are unsuited for such active project management.
    – MatBailie
    Commented Jul 24, 2020 at 20:51
2

Burndown charts are a useful way for teams to see whether or not they are making a steady progress towards completing the planned work in a sprint.

Lots of Scrum teams recognise that there is value in having stories completed steadily throughout a sprint, rather than being resolved towards the end of the sprint. For these teams burndown charts are a useful tool, as they can give early warning that the team is back-loading a sprint. They could review the burndown chart during their daily Scrum meeting and a poor burndown may be seen as an indication they have too much work in progress and are not completing stories early enough.

I would say in your case the burndown chart is working exactly as it should. It is indicating that you are backloading sprints.

Whether or not your team worries about this, is up to you. But the burndown chart is not the problem.

The install/deploy cycle could be shortened, but the nature of the business we're in (network appliances) can never make it very fast.

You know your business of course, but I doubt that this is impossible to do. Often it comes down to a trade-off of the benefits against an investment of time (and likely money).

Improve this answer
1
  • 1
    Nothing is impossible of course, but it is expensive. (This is a PM forum, so I won't go too much into technical details) Same as others above, you are correct: burndown chart tell me something, namely that sprints are backloaded. The thing is that it does not tell me whether the work is likely to complete or not, up until the Thursday of sprint's last week. I need to go to the sprint boards for that. Thanks for the response.
    – RomanK
    Commented Oct 23, 2016 at 15:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.