who manages burn down charts

Last post 07:15 pm May 15, 2013
by Charles Bradley
9 replies
11:01 pm April 27, 2013

who is best to manage product backlog burndown charts including tracking? Product owner?

who is best to manage sprint backlog burndown charts including tracking? Dev team?

since scrum master is a management position but doesn't manage team then can the scrum master "track" each burndown chart for the team to manage?

02:22 am April 28, 2013

<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
/* Font Definitions */
panose-1:2 15 5 2 2 2 4 3 2 4;}
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
a:link, span.MsoHyperlink
a:visited, span.MsoHyperlinkFollowed
@page WordSection1
{size:612.0pt 792.0pt;
margin:70.85pt 70.85pt 70.85pt 70.85pt;}
<body lang="NL" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal" style="text-autospace:none"><span style="font-size:10.0pt;font-family:"Arial","sans-serif"">Ik ben afwezig tot maandag 6 mei. Voor dringende aangelegenheden kunt u contact opnemen met de receptie (+31 318 581600). De receptioniste kan u
doorverwijzen naar een collega.

Met vriendelijke groet,

Sjoerd-Jaap Westra

+31.6.1095 0457


I am out of the office until Monday the 6th of May. For urgent matters please contact our receptionist (+31 318 581600). The receptionist can forward you to the right person.

Kind regards,

Sjoerd-Jaap Westra

+31.6.1095 0457</span><span style="font-size:8.5pt;font-family:"Tahoma","sans-serif""><o:p></o:p></span></p>

03:27 am April 28, 2013

A burndown chart should be an information radiator, like a scrum board. It might even be pinned on the board.

Since it's a team responsibility to keep information radiators up to date, it follows that it's a team responsibility to update a burndown. The person who does it should be the first person who sees it needs doing.

04:58 pm April 28, 2013

Agreed that it is the dev team's responsibility to update the chart. The main purpose of the chart is to help the team (everyone) make aware how much work (in terms of effort) is remaining. Each dev team member can take turn to update the chart.

08:58 am May 10, 2013

The theory state that each member of the Development Team can update the Burndown Chart because the team is self-organised.

But in real life I guess it’s usually the Scrum Master or the tool that you’re using that does the update for you. And I think it’s perfectly fine, because that way the team can fully focus on the stories and not doing (what some developers calls) “project administrative” tasks.

03:32 pm May 12, 2013

I feel the urge to advise you to be careful with assuming that it's okay for the Scrum Master to track the sprint burndown. I have several experiences suggesting that it makes it harder for the team to take ownership of their own progress. As a Scrum Master on a team that has just started, I usually take up that task initially. My intent however, is to hand it over to the dev team as soon as possible. It's their progress, not mine.

04:14 pm May 12, 2013

Usually when a project starts, I tell the team (so that it’s clear) that my role is purely to facilitate, not managing and that we’re 1 team joint with a common goal. As Scrum Master I believe there are enough way to create ownership within a team. My experience with Burndown Charts is that it can sometimes be time-consuming. Especially when you’re in a large team where a lot of WIP is going on. I do believe that the Burndown Chart can creates some kind of “team feeling” and I always recommend to show the Burndown after every Daily Scrum, because developers like seeing the line going down which is great! So I agree partly with you Paul.

What I don’t agree is when you said “it’s their progress, not mine”. As Scrum Master within a team (that shares a common goal) the progress is every bit as yours as it is of the team.

I’m just saying that I’ve seen a lot of teams where the SM updates the Burndown Chart and I believe there’s no problem with that. In my opinion the SM is as much of a team member as the developers. Of course, when the Development team can optimal self-organized themselves and do everything that would be great, but for a lot of teams that’s not the case yet.

02:39 am May 15, 2013

"It's their progress not mine" might be a bit harsh to say. Off course I'd be invested in the development team making progress, and I'd do whatever I can so that they can excel. Still, at the end of the day, it's their progress, not mine. Can I step in sometimes to model some of the skills required to be successful, sure. Think about it, how likely is it that the development team will self-organise and take responsibility for their progress as a team if someone else is tracking their progress for them? Have you considered working on not having a large team, and limiting WIP as a Scrum Master?

Regards, Paul

07:26 am May 15, 2013

Each member of the development team is responsible in managing the burndown chart


07:15 pm May 15, 2013

+1 to Paul's answers. Just because a lot of teams have the SM update the burndown doesn't mean it's right or correct to do so.

From the Scrum Guide:

The Development Team tracks this total work remaining at least for every Daily Scrum.
The Development Team tracks these sums daily and projects the likelihood of achieving the
Sprint Goal. By tracking the remaining work throughout the Sprint, the Development Team can
manage its progress.