4 ms·

It's a common metric used in the Scrum methodology. You start off the "sprint" with a set number of "story points" (say, 30 points), and end the sprint with zer

It's a common metric used in the Scrum methodology. You start off the "sprint" with a set number of "story points" (say, 30 points), and end the sprint with zero points. When you graph the team's progress over the course of the sprint, it should ideally form a linear, downward slope. https://en.wikipedia.org/wiki/Burn_down_chart https://en.wikipedia.org/wiki/Burn_down_chart

lubesGordi 10y ago
This kind of thing makes sense if you were doing something like digging a trench, where the progress can be linear because the task A is the same as task A - 1. Why would anyone think that given a variety of tasks that each would take the same amount of time?
- fbonetti 10y ago
  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.
- fidget 10y ago
  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.
- GrumpyYoungMan 10y ago
  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.
sib 10y ago
It's one of the misunderstood pieces of scrum to think that burndown charts should be linear. If a team of 5 has established a velocity of 65 story points / 2-week sprint, and they accept 5, 13-point tasks for the next sprint, you'd expect a burndown chart that would look almost horizontal for the entire sprint until the very end, when it would drop vertically to the x axis. You might get linearity if there were 65, 1-point tasks...
- fbonetti 10y ago
  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.
  - mrunkel 10y ago
    Exactly. My insistence is always that what happens inside the Sprint is the concern of the development team and nobody elses. However it's important to remember that the team itself should set their velocity in negotiation with the product owner. This shouldn't be set by some external force.
  - sib 10y ago
    Agreed - that is part of my own distaste for them...

lubesGordi 10y ago

This kind of thing makes sense if you were doing something like digging a trench, where the progress can be linear because the task A is the same as task A - 1. Why would anyone think that given a variety of tasks that each would take the same amount of time?

fbonetti 10y ago
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.
fidget 10y ago
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.
GrumpyYoungMan 10y ago
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.

sib 10y ago

It's one of the misunderstood pieces of scrum to think that burndown charts should be linear. If a team of 5 has established a velocity of 65 story points / 2-week sprint, and they accept 5, 13-point tasks for the next sprint, you'd expect a burndown chart that would look almost horizontal for the entire sprint until the very end, when it would drop vertically to the x axis. You might get linearity if there were 65, 1-point tasks...

fbonetti 10y ago
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.
- mrunkel 10y ago
  Exactly. My insistence is always that what happens inside the Sprint is the concern of the development team and nobody elses. However it's important to remember that the team itself should set their velocity in negotiation with the product owner. This shouldn't be set by some external force.
- sib 10y ago
  Agreed - that is part of my own distaste for them...