I agree. Being on the receiving end of Scrum feels like being an assembly line worker. I totally empathize with the business people who need some transparency into what the developers are working on week to week. Software is pretty abstract. I get that. But obsessing over burn down charts is the wrong way to go about it.

No one does, you estimate each task to have a different number of points, which modify the task's contribution to the burndown graph.

I guess the idea is that points should correlate to time (questionable), and if you're estimating perfectly, that should give you a linear burndown graph. Which is stupid. What might be less stupid is that if you want to get some idea of how well your team is estimating tasks, compared to i.e. this time last year, you could look at the volatility (across several sprints) this year compared to last year, and a lower burndown rate volatility might suggest that the team has improved at estimating the duration of tasks.

However, when you just focus on the volatility as a metric, then people start optimizing for it, which is not the point at all.

The theory is that a developer can estimate the approximate difficulty of a given task relative to other tasks and thus give a coarse estimate of how long a set of tasks will take. One is supposed to use this estimate, compare it against the amount of work actually accomplished in a given period, and then project ahead against estimates work remaining to get an idea of when the project will be finished. This is intended to help managers set expectations with customers and cut or adjust features if the date is too far into the future.

Unfortunately, what most organizations actually do is use the progress estimates to try to bludgeon developers into working faster, with entirely predictable bad effects.