Release burn down - do I need to estimates all user stories beforehand?

I typically use two lines when I create any type of release burn down/up. One line is for what I call 'original scope' (scope as of a given date which does not change). I create a second line to show 'new scope' which is any product backlog item that has emerged and estimated after that date. 

This allows us to see how things have changed over time and keep the release burn down flexible . 

Hope this helps! 

A release burn-down can be a helpful forecasting tool for a Product Owner (not a Scrum Master), and helpful to drive conversation at the Sprint Review.  As a Scrum Master I would encourage the PO to focus on no more than 6 2-week Sprints (1 quarter). I would also teach the PO to include a cone of uncertainty on the burn-down (using worst, average and best case velocity). By the way one can burn down points, number of Product Backlog items, or other ways to how work remaining over time.

For estimating you could try affinity estimation. This is quicker and less time consuming than poker, but not as accurate. On a large white board or wall you can put up columns labeled by estimates (fibonacci, t shirt sizes), and have the Dev Team place PBIs in the respective columns. 

I personally like the release burn-up, as you can add a line that shows the size of your Product Backlog and se the trend over time.

Most important, teach everyone who is looking at these charts about empiricism - that this is a forecast, outcomes can and will most likely change, and that nothing is for certain in the complex world we live in.

Hey I am trying to understand if I need to estimate all user stories first ,only then release burndown will give right data ?

Isn't the amount of work in your Sprint Backlog estimated?

Wouldn't a Sprint Burndown then forecast how much work remains before the next significant release becomes possible?

@Ian I understand that I can forcast based on burndown and velocity. I am talking here about reporting tool that can be used to visualize release progress.

Thx @chris-belknap. 

I will explore more on Release burn up . 

do you know if Release burn up or burn down charts are being used for reporting ? I learnt Scrum guide doesn't support Release planning hence not mentioned in scrum guide .

 I understand that I can forcast based on burndown and velocity. I am talking here about reporting tool that can be used to visualize release progress.

My advice is to rethink the purpose of a burndown, including any assumptions about a so-called "release burndown".

What would a meaningful burndown show, if it wasn't the progress towards release and the moment of empirical validation?