In Agile, requirements are usually expressed as User Stories, listed in a backlog. Prior to starting off a phase, a Scrum team normally estimates the stories that are considered necessary for the next release. This estimate is then compared to the team’s benchmark to have a high-level idea of how many iterations are needed to reach the status in which a release is feasible.
For instance, if the stories included in the first release are worth 360 story-points and we know that the team can work on an average velocity of 45 story-points per Sprint, we can expect this team to deliver said stories in 8 Sprints (360/45).
Since 45 is an average velocity, we can expect the team to have different velocities on each sprint: we can rely on the burndown chart to tell us whether the team is being faster or slower than their average velocity.
More importantly, using the specific project average velocity the chart will show us what progress we can expect if the velocity doesn’t change. Therefore, if after a few Sprints the average velocity of the team where 30 and not 45, the burndown would show us how we could expect the delivery to take 12 sprints rather than 8 (360/30).
The function of a burndown chart is to show a trend towards achievement of Sprint Plan/Estimate/Forecast. However, what a burndown chart does not do, is account for blockers. You can have a great trend going to show you are on track for a demo and then you hit a blocker you are not burning any more story points and you miss your deadline.
A scrum team does not need to look at a burndown to tell how the sprint is going – they should already be able to know it. It is mainly for the satisfaction of other Stakeholders.
Another problem, is when you estimate in story points, you have to plan each stand up on how much is done and how much is remaining, which is too much effort for a simple diagram. Burning points once the whole story is done, further reduces the value of a burndown especially if your stories are big. Then you have more issue when dealing with Bugs and Customer Incidents which cannot be captured in a burndown chart?
Also, when a burndown chart is not going to plan(burnup), teams tend to focus on improving the burn down chart rather than on understanding why it is going up, reasons being; unclear requirements, improper Stakeholder management etc. So one of the drawbacks of burndown charts is that it simplifies complex relations, dependencies and root causes into a simple chart, which can lead to simple firefighting activities rather than analysing the root causes and fixing them sustainably.