We just started with Scrum and are in our first sprint for a new software product. So far everything went well. As Scrum Master (former Project Manager) I build up all the knowledge I could find and had several workshops with the team to spread the word. The thing that gives me the feeling we are not doing it right is how/where/when to capture/collect the information that is necessary to draw the Sprint Burn Down Chart.

Right now I collect the information how much time is remaining for a certain issue during the daily Scrum Stand Up. That makes the Stand Up feel like a reporting meeting though, which I would like to avoid.

The only alternative I see is: Get the information via daily reporting email from each member. I´d like to avoid that since it adds to the reporting overhead the team already has (some are involved in different projects at the same time).

Is there a best practice for pulling the burn down information during Sprints?

1 Answer 1


The Team Should Update the Sprint Backlog Daily

Whether the Team is using a Kanban board or an Excel spreadsheet, there ought to be a canonical source for the Team's Sprint Backlog items. Members of the Scrum Team ought to update the Sprint Backlog at least daily, even if the only change is checking for tasks that meet the "definition of done" and marking them completed.

Mike Cohn says:

During the sprint, team members are expected to update the sprint backlog as new information is available, but minimally once per day.

When you have a Team-managed spreadsheet, this can be done by any member of the Team. Generally, it should be handled by the person who handles the last completed task in a story. For example, if you have a story with six tasks, and the last task is "QA the polish on the fob watch," then whoever is marking that task as done should also check the "definition of done" of the parent story to mark that as completed too.

If you have more of a Kanban-style tracking system, then the Scrum Master can review the Kanban board at the end of the day (or the start of the next) to see which tasks/stories have been pulled from the last column (usually QA or acceptance testing of some sort) into the "done" column. If all the tasks for a given story are in the "done" column, then the story should have met the "definition of done" and the points for those stories should be deducted from the points remaining in the current Sprint--in other words, the "done" column is your source of metrics for the the iteration's burn-down.

Alternatives for Gathering Burn-Down Data

Since a story is either done or not-done, the daily stand-up is a poor source of information anyway since it's a task-dependency meeting. However, not every Scrum process runs like a well-oiled machine. Here are some alternatives, but using them often implies that there's something wrong with your process that you need to fix; these solutions should generally be considered short-term patches on a broken process.

  1. Ask the Team to send the Scrum Master a daily done/not-done email for tasks they've volunteered for.

    Note that this moves the status pull out of the stand-up, which makes it somewhat acceptable, but it's covering the fact that task status is not transparent. It's also risky in that it may turn identification of process issues or road-blocks into "holding people accountable" or some other sort of blame game.

  2. The Scrum Master can follow up individually with task performers to see if completed stories meet the definition of done.

    There's nothing wrong with communication between the Team or the Scrum Master, or with a check-step process. However, Scrum Master sign-off is a sign of a Team that isn't fully self-organized. Likewise, if the Scrum Master has to validate that user stories are really done means there's a task or process that is missing or not fully visible within the Team's process. Oh yes...and it may also mean that there's a lack of trust on the Team, which is a sign that you have a group of individuals rather than a cohesive Team. There's a lot to consider with this one!

  3. Hold a separate "backlog-grooming festival" daily.

    The stand-up is for coordinating intra-day tasks between Team members. However, nothing in Scrum prevents you from having more meetings, or other types of meetings, or from performing status pulls outside the stand-up.

    While this particular quick-fix patches over tracking and transparency issues with the Team's process, there's nothing inherently wrong with holding additional process-related meetings during a Sprint. Please note that the time taken for these sorts of status meetings should be factored into the Team's story estimates, as they definitely create (potentially necessary) overhead that needs to be accounted for during Sprint Planning.

The take-away here is that the Sprint Backlog should give you sufficient data to create the burn-down chart. If not, you should definitely consider why the necessary data is missing from the process, and inspect-and-adapt as needed to gather that data without hijacking other essential Scrum processes.

  • 2
    I think this is another opportunity for CodeGnome's First Law, "Design the process first, then automate it.". Define what "Done" means, and how you want to track it. Then build the processes (some automated) to support that definition. +1 for a very solid answer.
    – MCW
    Dec 12, 2012 at 19:57
  • 1
    Here's CodeGnome's First Law for reference. cc: @MarkC.Wallace ...
    – jmort253
    Dec 13, 2012 at 4:46
  • 1
    Very good overview of the available alternatives. Thank you. Right now we are tracking 'effort (hours) remaining' for every task to plot the Burn Down instead of 'stories/tasks done', so getting the data from the Sprint Backlog is no option. We have an Sprint Backlog printout on the wall and during the Stand Up every team member updates the 'effort remaining' value for the tasks he worked on. I like the idea of an 'backlog-grooming festival' and will bring it up during the next Retrospective.
    – perelin
    Dec 13, 2012 at 11:22

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.