Release burndown chart

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.

> 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.

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

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.

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

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

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

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. 

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.

• 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.

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?