What can I constructively say when looking at the Sprint Burndown

Question

During our daily standup we examine our Sprint Burndown to look at how we're getting on against the goal line.

I often struggle for constructive things to say about the graph and tend to resort to:

• That's not looking so good
• We're on track

I feel that this often means that the burndown isn't given the weight it could be as a forecasting and planning tool.

I don't believe that we should idly watch as a team falls behind. I want to take the progress information we've got and use it to rescue the sprint while there's still an opportunity to do so.

So, what can I say while I show the burndown chart in a way such that it constructively aids our planning while we're discussing our tasks for the day?

Answer 1

TL;DR

First of all, never "walk the board" or huddle around a chart for your daily stand-up. The meeting is for dependency coordination, not reporting or trend analysis. Staring at a burn-down doesn't help the team coordinate!

Secondly, the goal of a Sprint is to meet the Sprint Goal. If you routinely meet your Sprint Goals with a choppy burn-down, or even if you meet your goals without completing the burn-down, your Sprints are still successful! Less-than-ideal trend lines present opportunities for process improvement, but having an ideal trendline for your burn-down is not the point of Scrum!

Optimize for Flow

You're using the wrong tool for the job. While burn-down charts can be useful for projecting trends for longer Sprints, or provide transparency to stakeholders, it sounds like you're abusing the metric as a way to hold the team accountable to some original forecast.

The daily stand-up isn't really designed as a ceremony to huddle around a burn-down chart. It's really a dependency coordination meeting, and a mini-meeting for the team to plan the day's work.

Instead of focusing on the burn-down chart as your primary metric, try focusing on team coordination instead, which often smoothes the burn-down trend line as a byproduct of improved flow. The general guidance is that a Sprint Backlog Item should be 1/2 to 2 days of effort. Did the team complete the work they expected to complete yesterday? Is the work planned for today blocked by dependencies that weren't completed yesterday? Is there newly-discovered work that needs to be planned, or unplanned work that's eating away at team capacity? Let the team call out those things during the daily stand-up, and try to have everyone walk out of the stand-up with a plan for addressing them during the workday ahead!

When to Address Trend Lines

As a general rule of thumb, a burn-down chart is not generally useful for the Development Team within a Sprint. However, it is often a great trailing metric to identify problems with story sizing, dependency management, and flow. From a Development Team perspective, the best time to talk about burn-downs is probably the Sprint Retrospective.

Work comes in all sizes. However, since work is either done or not-done, a burn-down that flatlines until the end of a Sprint is often an indicator of work items that are too large (e.g. more than 4-16 wall-clock hours each) or a poor (or even missing) continuous integration process. It may also indicate hidden blockers or process problems that aren't being raised in the daily stand-ups or reflected in the team's working agreements.

If you have historically had a smoother burn-down, then the chart can be a useful warning signal of hidden problems. However, if your burn-down has always been late to converge, then it's grist for the mill when the team addresses its planning/estimation or dependency-management processes during the Sprint Retrospective.

Answer 2

All graphs of this type are, in my opinion, designed to assist you to plan and prioritize. These are not the kinds of activities that I think should occur during a normal daily standup; these are management activities, not control activities. Having said that, I work with a chart that isn't precisely a burndown chart, but is analogous. My chart has

• the current burndown line,
• a reference line for the worst case scenario, and;
• series of escalation thresholds.

If the burndown curve is approaching the threshold, the team can take action swarming or stretching, and I can take action to prepare proposed plans for when the curve crosses the threshold.

The first threshold is actually just an "inform" threshold - if the curve crosses the threshold then I inform a (defined) set of stakeholders that we have a problem and that we're preparing alternative courses of action. That way nobody is surprised if we need to replan, and the stakeholders have an opportunity to assist.

If the curve crosses the escalation threshold then the stakeholders & I have to replan. In my projects that usually involves deferring some work to a future "sprint-analogue" - we readjust the scope of the remaining work to bring the burndown curve back inside the control threshold.

As I said, I work in "scrumbut", so I don't have some of the constraints of scrum. That said, I submit that scrum is a method for controlling work. If the burndown curve crosses a threshold, then the Sprint is out of control, and needs exception management. If for example the work required to complete on time significantly exceeds the team's maximum historical velocity, then I think the problem cannot be solved by scrum. ( As I said, I am not a scrum member, so I could be wrong, and will be happy for correction.). But the goal of the burndown chart is to avoid that situation. The goal should be to take action when the work exceeds some lower threshold- perhaps the average velocity?

Answer 3

You don't have to say constructive things about the burndown; it's just a factual display and you don't hurt its feelings by saying it's not looking so good today.

Instead, you need to ask the team the question "how are we going to fix this?".

That basically means that if people agree that the burndown is failing, it's time to sit down with everyone and talk about what can still be done this sprint, what isn't as important and can be dropped, whether there's a more efficient way to complete the tasks that still need doing, etc.

Also, talk about the reason things aren't going as fast as intended. While an in-depth "how did this go wrong" is more a retrospective thing, a quick "will whatever went wrong cause more trouble for us during the rest of the sprint" is important, otherwise you'll be having the same discussion the next morning.

Remember also to keep your eyes on the goal. While it's common to select an amount of work that seems doable at the start of the sprint, you also pick a goal of "what do we want to accomplish", and it's fine to remove some items or change some plans to reach the goal in a different way.

Answer 4

I don't believe that we should idly watch as a team falls behind. I want to take the progress information we've got and use it to rescue the sprint while there's still an opportunity to do so

The burn down chart is primarily a measure of how well the team estimated.

They aren't falling behind.

There probably is nothing you can do to 'rescue' the sprint.

(Assuming its a nice constant line and not going to curve down towards the end of the sprint) What you can do, is manage the stake holders expectations and tell them its going to be late before they are surprised by getting it late.