Who is responsible for creating and updating the Burn down chart?

Last post 08:45 pm November 27, 2019
by Timothy Baffa
11 replies
Author
Messages
07:17 pm November 25, 2019

By the Scrum guide, use of the Burn down (up) chart is not mandatory. In real life, you can find it very useful.

  1. If we decide to us it, who do you think is responsible for creating and updating the Burn down (up) chart on daily basis?
  2. If the PO is in charge of this, how is it possible for him to keep this chart up to date on a daily basis because he is not participating in the Daily Scrum meeting?
  3. When do you update Burn down (up) chart? Is it just after Daily Scrum, or after some other activity, maybe on short break?

I would appreciate if you can be very specific.

Thanks

Dejan

07:44 pm November 25, 2019

Dejan, one of the things you should try to get used to is that neither Scrum or Agile are very prescriptive, and it is unwise to simply take what works well for others and adopt it without understanding why it is a good practice for that situation.   

You should not come to this forum looking for specific answers.   You are already working through some of your own questions around this topic.   Continue exploring what makes sense for you and your team.

A Burndown/Burnup chart helps the Scrum Team visualize where they are in the sprint, and whether the Sprint Goal (or Sprint Forecast) is on track.   What I can tell you is to consult the Scrum Guide to understand the roles that benefit from such transparency and information radiation.   This understanding should help guide your decisions on who should maintain this and when.

07:47 pm November 25, 2019

Shouldn’t it be done by the first person who sees that it needs doing?

08:37 pm November 25, 2019

Although the scrum guide does not specifically say so, my understanding is the development team is responsible for preparing and maintaining the burn-down chart.

 

10:20 pm November 25, 2019

First, I am going to agree with @Timothy Baffa and encourage you to take his advice.  Second, @Ian Mitchell has the best one line answer you will ever see for your question. Here are my answers

1. Anyone that is involved in the work and sees the burndown chart is not current and accurate.

2. This should never happen because the burndown chart is for the work being done during the Sprint by the Development Team. So why would anyone but the Development Team be responsible for updating the information?

3. As @Ian Mitchell mentions, when it needs to be done.

Burndown charts are a tool for the development team to communicate their progress. But they can also be used as weapons against a development team by individuals that do not understand their purpose or the methods of agile software development.  As you said, it can be useful but it can also be a complete waste of time if too much emphasis is put on having the "perfect" burndown.  So I caution you to be absolutely sure that the tool will be useful for everyone and not something that will be used wrong.  

04:47 am November 27, 2019

Agree with Daniel Wilhite (especially the last paragraph). There must be an alignment or an understanding of why you are going to use burn down chart.

I had an experience wherein it was used as a weapon against the team that they are not doing their work simply because the chart is bad (or at least what they understand that it is bad).

09:25 am November 27, 2019

Thanks for all great thoughts.

I was just wondering what are the ways for PO to track the Sprint progress toward Sprint Goal?

Since Daily Scrum in not an option, my thought was that using of Burn down (up) chart will tell PO that Dev team is on track every single day.

10:44 am November 27, 2019

I was just wondering what are the ways for PO to track the Sprint progress toward Sprint Goal?

Shouldn't the Product Owner trust the Development Team to meet the Sprint Goal, and to track progress themselves? If the Goal appears to be under threat, wouldn't Scrum Team members collaborate to resolve it?

12:57 pm November 27, 2019

Sure. Thanks

03:46 pm November 27, 2019

One thing about Scrum is that it requires a lot of trust and a measure of hope.  As @Ian Mitchell said the PO will have to trust the Development Team to raise issues or potential problems if they feel it will impact the Sprint Goal in any way, either negative or positive. In the end no one is going to consciously do anything that will impact the team's ability to deliver value to the stakeholder. 

Let me ask some other questions that might help put some things into perspective.  How does the Development Team know that the items in the Product Backlog are ordered in a manner that ensures they will be doing the right things in the right order? How do the stakeholders know that the Scrum Team will be working on solving the problem that they are facing?  There is a lot of trust involved.  Open and honest communication is required without fear of retribution or blame being placed. As the Scrum Guide states in the opening sentence of the section on the Scrum Values:

When the values of commitment, courage, focus, openness and respect are embodied and lived by the Scrum Team, the Scrum pillars of transparency, inspection, and adaptation come to life and build trust for everyone. 

04:05 pm November 27, 2019

If it helps any, I suggest visualizing the Scrum Team without hierarchy. Scrum Master, Product Owner, and Development Team share the same goals and perform their roles for the collaborative, horizontally not vertically. The Product Owner is not a Management role for this purpose and so there's nothing for them to 'track' since the Dev team is accountable for the Sprint Backlog and their ability to complete the Sprint Goal. This ownership requires them to collaborate and communicate with the Product Owner anytime they need to.

In that light, the burndown tool could be useful to show specific progress in the Sprint rather than all the items in the Sprint. For example, limit it to Sprint Goal related work if the team is not 100% focused to the Sprint Goal and has items in the Sprint for existing product support/maintenance, dependency work, service desk, etc.

The benefit I've seen come from Burndowns is to help identify the impact of work that isn't visualized in the Sprint (hidden work, external requests, distractions etc.). Once team is able to have all work captured in the Sprint, the Daily Scrum typically ends up removing the need for the tool. 

 

08:45 pm November 27, 2019

Since Daily Scrum in not an option,

Dejan, why don't you believe the Daily Scrum is an option for the PO to assess Development Team progress towards meeting the Sprint Goal?