Skip to main content

Release burndown chart

Last post 03:20 pm September 11, 2019 by Harshal Rathee
10 replies
05:24 am October 29, 2013

Hi,

I am working as a Product Owner and I would like to introduce Release burndown chart to my product. On web side: http://www.mountaingoatsoftware.com/agile/scrum/release-burndown I found that Scrum Master is responsible for it. "The release burndown chart is updated at the end of each sprint by the ScrumMaster."
I did not find anything in Scrum Guide about Release burndown chart.
So my question is:
Who is responsible for updating release burndown chart?
Thank you :).


08:08 am October 29, 2013

Hi Izabela

The release burn-down / burn-up was part of earlier Scrum Guides but has been removed. See an article explaining about that: https://www.scrum.org/About/All-Articles/articleType/ArticleView/articl….

Even if not required, the chart is still a good tool to track progress and provide visibility. So if you as a PO want to introduce it, do it yourself or ask the team to provide it. Maybe they have a kind of Sprint-DoD to update the chart. If so, you make it the responsibility of the team.
The Scrum Master may help the team to create the chart or to setup the rules for updating it, but I wouldn't say that it is his/her responsibility to draw it.

BTW, I much prefer Release Burn-Ups to Burn-Downs because it allows to see the total of all planned items for the release in addition to the progress.

Regards, Jörg.


08:33 am October 29, 2013

> Who is responsible for updating release burndown chart?

In an agile or lean way of working, a burndown chart should be updated by the first team member who sees that this needs doing.

This principle of "going to where the work is" holds for updating information radiators as well as for expediting work in the value stream.


03:05 am October 28, 2014

What is the purpose of a trend line in burn down chart?


03:29 pm February 9, 2016

The role of PO is to be able to work with stakeholders about releases, increments, value etc - all those require some predictions in planning. Burn down is one of options. It is in PO best interest to have data and tools to work with it. SM whose main responsibilities is to make sure left work is transparent to everyone. One of the option is to introduce burndowns, charts or other.

Choosing best tool to have should be output of discussion among scrum team. Healthy team will provide solution without need to point out who is responsible for it.


02:51 am February 18, 2019

Trendline in burn down chart is a way to predict how many sprints a project will take.


04:53 am August 29, 2019

The above link does not work, you can now find it here...

https://www.scrum.org/resources/gone-are-release-planning-and-release-turndown

 


01:53 pm August 30, 2019

Who is ultimately accountable for the feature releases of the Product? If a Product Owner doesn't want to jump in and take ownership of their release progress what message might that send to the Development Team? 

I find that the Sprint Review can be a very useful place to collectively update things like Release charts, Roadmaps, etc. based on the work completed and any new learning throughout the Sprint. 


12:15 pm August 31, 2019

Why not Consider the introduction of the flow metrics (Cycle Time, Throughput, WIP, and Work Item age)?

Velocity only makes sense when there's no update in the backlog and over the team. It's hard to see.

There's much more predicability when you do it.

Take a look at the Daniel Vacanti's book.


02:34 pm September 10, 2019
  • I would recommend a Burn Up Chart over a Burn Down Chart, because:
    • With a Burn Down Chart: If Scope/Forecasted Scope increases, you will have to Burn Down the plotting line into negative values (under the x-axis) since you started at a scope value that is no longer high enough.
    • With a Burn Up Chart: If Scope/Forecasted Scope increases, you simply raise the plotted scope line. Updates are easier and the chart is more intuitive.
  • No particular role (SM, PO, DT) is solely responsible for updating charts/artifacts. However, as a Scrum Master is a servant-leader, it may necessarily fall into their hands (aim to facilitate it getting updated). The goal should be to encourage self-management and self-organization. 

@Olavo - We've done several analyses on various metrics for predictability with our teams. We have observed that some teams are more predictable with Story Points; whereas some teams are more predictable with Throughput, etc.. So to add to what you said, it is good to understand all metrics available to find what works best for predictability. Further, humans are great at "gaming" metrics, this can be good and bad. Exercise caution with metrics being used and ensure they are valuable, and definitely make sure they are not putting micro-management vibes on the team.


03:20 pm September 11, 2019

I would recommend a Burn Up Chart over a Burn Down Chart

Don't you think the purpose of both charts are different ? Burn Up chart is to track the total scope independently from the total work done whereas Burn Down chart is to track the total work remaining.

With a Burn Down Chart: If Scope/Forecasted Scope increases, you will have to Burn Down the plotting line into negative values (under the x-axis) since you started at a scope value that is no longer high enough.

What problem do you see if the scope increases or decreases considering sprint goal is met ? Isn't it focused to increase transparency in team rather judging the trend line variations? 

 

 

 

 


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.