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?

  • Not sure I understand what you mean by 'how can I present'. Are you asking about comments you can make about the chart? Or information you can add to the chart? Or something else?
    – Sarov
    Commented Jul 26, 2018 at 13:46
  • What comments, I'll clarify the question
    – Liath
    Commented Jul 26, 2018 at 14:32

4 Answers 4



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.

  • While I agree with your points about the sprint goal being to meet the sprint goal and the team should not become overly focused on the board or burn-down charts, both offer a lot of at-a-glance information that the team can use to assess the current state of the sprint.
    – Daniel
    Commented Jul 30, 2018 at 3:12
  • @Daniel Absolutely! A burn-down chart can be a useful artifact that provides project transparency. It can also be an information radiator, provided it’s highly visible. It just shouldn’t be a routine talking point for the Scrum Master during the stand-up, nor be used as an accountability tool.
    – Todd A. Jacobs
    Commented Aug 2, 2018 at 16:40

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?

  • 1
    I like the sound of your chart, particularly being metrics-driven. But allowing people other than Scrum Team members to alter the Sprint Backlog sounds wrong.
    – onedaywhen
    Commented Jul 27, 2018 at 14:17
  • 1
    I actually agree with most of what you've written. I just disagree that a burn-down chart should routinely be grist for the mill at the daily stand-up. If a Sprint is out of tolerance, or the Sprint Goal is at risk, a brief stand-up is unlikely to be the right forum for the team or stakeholders to investigate or take corrective action.
    – Todd A. Jacobs
    Commented Aug 2, 2018 at 8:14

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.


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.

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.