who manages burn down charts
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?
<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">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";
mso-fareast-language:EN-US;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.E-mailStijl17
{mso-style-type:personal-compose;
font-family:"Arial","sans-serif";}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";
mso-fareast-language:EN-US;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.WordSection1
{page:WordSection1;}
--></style>
</head>
<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>
</div>
</body>
</html>
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.
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.
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.
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.
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.
"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
Each member of the development team is responsible in managing the burndown chart
http://www.agiledistributed.com/
+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.
"The Sprint burndown chart tracks the amount of work remaining in the Sprint day-by-day. The burndown chart is updated daily and is visible to the team and stakeholders. This activity is part of the ScrumMaster’s duty to facilitate the Scrum Process. This activity is part of the ScrumMaster’s job to satisfy stakeholders as the chart allows the team to easily see how it is trending on committed deliverables. This information allows the team and the Product Owner to discuss any necessary adjustments to the team’s commitments for the current Sprint in a timely fashion. "
Ref,
http://www.agileadvice.com/2014/02/06/scrumxplean/the-rules-of-scrum-yo…
Chandramouli,
The Scrum Guide neither assigns responsibility to the Scrum Master for burndown chart maintenance, nor states that burndown charts are even a part of Scrum.
They can be a useful tool to promote transparency, which is a part of the Scrum Master's responsibility to both the Scrum Team and the organization, but nowhere does it prescribe the use of burndown charts.
Be very careful in the future referencing other sites claiming to promote Scrum. More often than not, such sites have an incomplete or incorrect interpretation of Scrum.
I got confused with the details provided in the ref site, so wanted to post it to check. Thanks for the details response.
Based on the scrum.org's guide,:
The Product Owner is responsible to monitor the progress of the whole project toward its
goal. This should be done at least once per Sprint Review. The Product Owner determines
the amount of remaining work and compares it to the remaining work of the previous
Sprints, and forecasts the completion date of the project.
It’s also common to add a trend-line to the burn-down chart, to get a rough estimate of the
completion date. This estimate is based on the assumption that no new items will be added
to the Product Backlog and the development capacity will stay the same. It’s expected from
a Product Owner to only use this as a guide, and come up with a more reliable forecast for
the completion date.
Dev team has to input the progress within the sprint.
Based on Mountain Goat Software, release burndown chart is updated by ScrumMaster:
https://www.mountaingoatsoftware.com/agile/scrum/scrum-tools/release-bu…
Development team should update their respective tasks and items actual effort within the sprint. During inspection or demo, Product Owner should be able to present this to stakeholders. Scrum Master should guide the team. Those with PM background will automatically tell you that it should be the Scrum Master. If we're talking about scrum and not other frameworks, follow the guide created by the creators of Scrum. I used to think that it's also the Scrum Master. But honestly as SM and PM, I do it. It may not be ideal but client is happy so far. I'm going to change that in our next project.
who manages burn down charts - No one as they are not required in Scrum :) = Everyone if they decided to use it !
Now let's consider the situation where the team is using burn down charts for tracking its progress. If this is not mandatory in Scrum how would have this happened? Probably through retrospective or process improvements suggested by some one (or few) and accepted by the entire team as a good thing to follow. So if the team collectively agreed to follow a particular form of information radiator who is responsible to manage it? Yes! The team collectively should manage it. There are tools automatically update this graph as long as the team simply updates each PBI and tasks to completion (JIRA, VSTS, RTC, QC,etc). Who ever is savvy or takes pleasure in configuring these tools (consider me in :)) can enjoy making sure this Widget/viewlet is working on your dashboard and showing right information.
+1 Uma
So, I think I am off the beaten to all of you here. UPDATE being the word I am stuck on. I use Jira and I do not update the burn down I have set up. I would not know what progress to update. I would not dare go in and start marking tasks or stories as complete or done. Now as the scrum master for my teams I do have to stay persistent on my coaching with them on cleaning up their own stories\tasks.
I do monitor the burn downs and when I see things not moving when I know they are I just nudge them to go update their work. I do the same with Kanban just a little differently.
The PO's I have worked with don't even know what a burn down is unless I give them training. And even when I explained to them how important a tool it they is usually still look to me to give them the info even with access.
I agree with Uma when he says, that "The team collectively should manage it"
Extending same notion, I would continue that as per Scrum guide, it is team's responsibility. Team constitutes of Scrum Master and Dev Team, but both have different work-to-be-done for Burndown chart i.e. Dev team to update remaining hours on regular/daily basis (in JIRA or VSTS) and Scrum master to collate that data and create a burn down chart.
Practically, dev team member might forget to update that on daily basis, so as a scrum master, I would prepare burn chart every two days.
The sprint burndown chart is also a representation of the remaining work in the sprint backlog. The developers manage the sprint backlog. In that sense, it is more feasible for them to manage the burndown chart. The Scrum guide did not specify anything regarding managing these charts. But let us not forget that the team is self-organizing. So in cases like this, whichever works best for them should be the appropriate route.
Cheers,
Harley
Dear Friends, let us stick to Scrum Guide. It says
The Product Owner tracks this total work remaining at least every Sprint Review. The Product Owner compares this amount with work remaining at previous Sprint Reviews to assess progress toward completing projected work by the desired time for the goal. This information is made transparent to all stakeholders.
Various projective practices upon trending have been used to forecast progress, like burndowns, burn-ups, or cumulative flows.
none of the comments mention what the burndown is and why it used. unfortunately if you want to get an understanding of what the burndown is you have to look elsewhere to get it.
The burndown is a process metric which reflects the health & reliability of the teams process.
As with all process metrics (also known as process condition) you use them as follows
- for a stable process
-- to seek out process problems while the process is occurring
- for an improving process
-- to determine if the result of you emperical based experiment has the expected result on your process condition.
so who manages the burndown - if used correctly by the team... the developers. Since it is they who are performing all the process related changes.
every other use of the burn down relates to managing symptoms and therefore incorrect.
This should be updated by the Development team but the Product Manager should know how much work is remaining by looking at it. Scrum master is just a facilitator for the Scrum and it does not tell anywhere in scrum guide that Scrum master should maintain burndown chart. Burn down chart will help the product owner to give fare commitments to the stakeholders. At Sprint planning, the Product owner should know the capacity of the team for the upcoming sprint to set the right sprint goals for development team.
This should be updated by the Development team but the Product Manager should know how much work is remaining by looking at it.
Correct, the Development Team updates the burn-down, perhaps you meant to state Product Owner, not Product Manager?
At Sprint planning, the Product owner should know the capacity of the team for the upcoming sprint to set the right sprint goals for development team.
Are you sure the Product Owner is the one using capacity to determine what can be done in the Sprint? And is it the Product Owner or Scrum Team who crafts the Sprint Goal?
I have not used a burndown chart in my current team or in the two assignments before this. It has not been needed. If the sprint backlog is sufficiently transparent, then you can just look at it and see the progress.
What worked just fine for us is to have a physical kanban with swim lanes for PBIs and sticky notes for tasks. We agreed that normally a sticky note is half a man day of work or less.
In a development team of 4 and 10 working days in a sprint, you have 80 sticky notes or more. Enough to let the law of large numbers apply, meaning the average size is pretty reliable, as well as the pace in which they travel across the board.
If you look at the kanban at the Daily Scrum on the third day and see 2 or 3 stickies in Done, you are behind schedule and may need to adapt. If half the stickies are in Done, you are probably ahead of schedule and may need to pull more work into the sprint.
...it does not tell anywhere in scrum guide that Scrum master should maintain burndown chart.
The only reference I can find in the Scrum Guide on burn-down/burn-up charts is a "for example" statement but nothing that prescribes it as part of Scrum. That statement is immediately followed by this statement.
These have proven useful. However, these do not replace the importance of empiricism. In complex environments, what will happen is unknown. Only what has already happened may be used for forward-looking decision-making.
I searched the guide for the word "progress" and it is mentioned 13 times. It says that progress is tracked on many facets of the artifacts and the Sprint. But no where does it say how to do it.
As @Henri mentions there are multiple ways of showing and determining progress. I have never used a burn-down or burn-up chart with any teams I have been a part of as either Scrum Master or Development Team member. Scrum/Kanban boards or just the conversations during the Daily Scrum have always sufficed for the purpose. In the end, it is up to the Development Team to decide how to track and make transparent the progress for which they are responsible. It is up the PO to track and make transparent the progress for which she is responsible. From what I can determine the only progress a Scrum Master is responsible for is the team dynamics and Scrum adoption/appreciation. I think that is also up to the Scrum Master to track and make transparent in some ways.
Nowadays JIRA has become the most popular tool for managing all these charts, release burndown, product burndown, scrum/sprint burndown and all other metrics related to Agile-Scrum projects are readily available and auto-generated right in front of our screens
+1 to Daniel Wilhite's comment.
I strongly believe the updating of burn down charts by scrum master can occur only when it is considered an impediment on the smooth progress of the development team,once in a while.It should be more of an exception than a rule.Otherwise ,the goal of self-management of the development team may be interfered with ,consciously or unconsciously by the scrum master.