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.

I think you're getting at the heart of why burn down charts are so pointless. The shape changes sprint to sprint, depending on what kind of stories you take on. If the sprint is entirely high pointed stories, your chart will be mostly horizontal. If the sprint is entirely 1 pointers, the graph will look like an exponential decay.

Since the shape is always different, there's virtually zero useful information to take away from it.

Some people in this thread claimed that burn down charts are useful for finding out a team's capacity. I disagree - you don't need a chart for this. If your team has a target velocity of 30 points and routinely fails to meet it, reduce the target velocity. Likewise, if the team routinely completes all of their work well before the end of the sprint, slightly increase the target velocity.

Actually it is a good metric. However the metric is not a linear shape, but within 20% of linear. If you are not within 20% you need to do something about it. In general once you are within that further effort towards perfection is not desirable.

Remember the real goal: money. Sometimes it is money from sales, sometimes it is money saved. (even in case of a charity where there are higher goals money is a proxy for the real goal since it can be applied to the goal in some other way). If management can predict with reasonable accuracy when features will be done they can translate that into how much it will cost. Then they compare cost vs expected rewards (expected rewards is the job of marketing) and decide if they should focus on feature A, B, or both.

Note that many managers fail to understand error bars. There is no way to know exact numbers. However you can predict your likely error, and if the error is too high you can spend more money to reduce the error.

I recommend the book "how to measure anything" for more detail.

In the mean time when management wants perfect linear burn down charts, there is only one way to achieve them: overestimate your stories, finish them early and then go home. If you are paid for a 40 hour week you should average about 15 hours a week, but once in a while you will need to work a 40 hour week (60 hours every 10 years or so). Most management considers this unreasonable (for obvious reasons), but if a perfect linear slope actually is that important to them they will agree.

It's a metric that can help identify patterns within a team. It only works if everyone is honest with the amount of work they've done, and they consistently report time in the same manner.

A pretty common burn down chart would have a somewhat linear slope in the beginning, a somewhat less sharp slope in the middle (mid-sprint slump), and a sharper decline to close out the sprint strong. Notice I said common (more likely to happen) and not ideal, because there truly isn't such a thing as an ideal burn down chart without context. What is ideal to one person/team may be completely different to another.

I personally track my time spent in an IDE slinging code or in app testing using an external tool to help me identify patterns. Purely in terms of time spent in IDE/app, Fridays are my least productive day by about an hour. Mondays are my second least productive. I am at my peak on Wednesdays. Thus I try to shuffle heavy loads to mid-week and the easy, gimme-task for Mon/Fri.

Just like a burn down chart, there isn't some ideal way productive time spent at work should appear on a graph. Well, I guess ideal is 100% of the day in IDE/app , but productivity would plummet. Humans just are not that efficient. Graphing my time gave me insights on how my week/month plays out. Burn down charts should do the same at a team level.

I think so it was from the show Silicon Valley. I know way to base your facts on a show. But I did hear that the show had at least one real engineer advisor.

Even so with regard to work vs. time what determines the time? Launch date?