5 ms·

Burn down chart?

by wjamesg 10y ago

Burn down chart?

zer0tonin 10y ago
Nice excel graph with the number of "points" burned each sprints.
fjdlwlv 10y ago
It's a project management strategy named for how it makes you want to burn down the office.
fbonetti 10y ago
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...
polysaturate 10y ago
An actual serious answer: It's a line chart that shows story points starting at the top left in the beginning of the sprint. Which shows all points to be done, trending towards 0 points with 0 days left in the sprint, in the lower right. Linear means that the same points are done each day to allow the line to be perfectly linear between the top left and bottom right.
- zentiggr 10y ago
  Sounds like exactly the sort of not-actually-a-real-metric metric that would entrance a number cruncher. Forget those moments of excellence where everything gels and you could get days or weeks ahead... Sigh.
  - bluGill 10y ago
    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.
ge96 10y ago
This whole time I thought it meant how long your money has going to last.
- dgritsko 10y ago
  Are you thinking of the term "burn rate", perhaps? https://en.wikipedia.org/wiki/Burn_rate https://en.wikipedia.org/wiki/Burn_rate
  - ge96 10y ago
    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?
throwaway343534 10y ago
It's pointless gimmicky make-work that presents your upper management with the fantasy that development work is not a difficult bespoke engineering effort, but rather an assembly line like they studied at business school. In order to pull off this sleight of hand, real work is broken up into elastically-sized multiples of a subjective metric called "points" which the team is allowed to estimate. This estimation game is key as it builds buy-in from the team by appearing to "give them a seat at the table." Chunking the estimations into sprints is a smoke screen to keep the scam going. Having acquired the buy-in from the people actually doing the work, the estimates are immediately converted to commitments by tracking progress on a burn down chart and telling upper management that the project will begin at 100% work remaining and proceed in a steady, linear assembly line fashion to 0% work remaining after the time allotted. Deviations from a steady downward slope are interpreted as failures of the development team which paradoxically reinforces the standing of the chart presenter because they are able to "show the numbers". Unchecked, this ultimately elevates them to diety-like cult standing. As the flawed assumptions underlying the chart are never questioned after the initial implementation, the use of burn down charts ultimately ends with: - Blue Pill Ending: the company shoots itself in the foot by firing the team for failing to make the burn-down chart linear - Seller's Market Ending: the team gets wise to the con and leaves the company - Red Pill Ending: the process manager is fired after heroic intervention by the technical leadership A process manager that wants to show up with their PMI certification and their burn-down charts faces a precarious end-game.
lostlogin 10y ago
This seems to have triggered the most cynical and disillusioned thread I've ever read on HN, and there have been a couple. Well done. It would be interesting to fish out a few other HN reviews of business practices, but I don't even know the correct terms to search as they generate instant disinterest.

Burn down chart?

by wjamesg 10y ago

Burn down chart?

zer0tonin 10y ago

Nice excel graph with the number of "points" burned each sprints.

fjdlwlv 10y ago

It's a project management strategy named for how it makes you want to burn down the office.

fbonetti 10y ago

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...

polysaturate 10y ago

An actual serious answer: It's a line chart that shows story points starting at the top left in the beginning of the sprint. Which shows all points to be done, trending towards 0 points with 0 days left in the sprint, in the lower right. Linear means that the same points are done each day to allow the line to be perfectly linear between the top left and bottom right.

zentiggr 10y ago
Sounds like exactly the sort of not-actually-a-real-metric metric that would entrance a number cruncher. Forget those moments of excellence where everything gels and you could get days or weeks ahead... Sigh.
- bluGill 10y ago
  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.

ge96 10y ago

This whole time I thought it meant how long your money has going to last.

dgritsko 10y ago
Are you thinking of the term "burn rate", perhaps? https://en.wikipedia.org/wiki/Burn_rate https://en.wikipedia.org/wiki/Burn_rate
- ge96 10y ago
  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?

throwaway343534 10y ago

It's pointless gimmicky make-work that presents your upper management with the fantasy that development work is not a difficult bespoke engineering effort, but rather an assembly line like they studied at business school. In order to pull off this sleight of hand, real work is broken up into elastically-sized multiples of a subjective metric called "points" which the team is allowed to estimate. This estimation game is key as it builds buy-in from the team by appearing to "give them a seat at the table." Chunking the estimations into sprints is a smoke screen to keep the scam going. Having acquired the buy-in from the people actually doing the work, the estimates are immediately converted to commitments by tracking progress on a burn down chart and telling upper management that the project will begin at 100% work remaining and proceed in a steady, linear assembly line fashion to 0% work remaining after the time allotted. Deviations from a steady downward slope are interpreted as failures of the development team which paradoxically reinforces the standing of the chart presenter because they are able to "show the numbers". Unchecked, this ultimately elevates them to diety-like cult standing. As the flawed assumptions underlying the chart are never questioned after the initial implementation, the use of burn down charts ultimately ends with: - Blue Pill Ending: the company shoots itself in the foot by firing the team for failing to make the burn-down chart linear - Seller's Market Ending: the team gets wise to the con and leaves the company - Red Pill Ending: the process manager is fired after heroic intervention by the technical leadership A process manager that wants to show up with their PMI certification and their burn-down charts faces a precarious end-game.

lostlogin 10y ago

This seems to have triggered the most cynical and disillusioned thread I've ever read on HN, and there have been a couple. Well done. It would be interesting to fish out a few other HN reviews of business practices, but I don't even know the correct terms to search as they generate instant disinterest.