4 ms·

> We estimated the amount of time each task would take, assigned it points based on that, and we'd fill our task list in such a way to try to make the estimatio

by darkr 8y ago

> We estimated the amount of time each task would take, assigned it points based on that, and we'd fill our task list in such a way to try to make the estimation close 40 hours of work. The concept of story points was invented as an attempt to solve the problem of developers reliably estimating the amount of time a given task will take. If you're directly equating story points to time then you're doing it wrong.

t0mbstone 8y ago
And yet, story points are used to estimate how much work a team can get done in a sprint, which is a time measurement... and they are used to track velocity, which is used by management to figure out when a project might be completed (also a measurement of time). "Oh, story points are just about the complexity" Oh really? Why does complexity matter, if not to function as an indicator of how long something might take to finish? Anyone who is telling you that story points aren't directly related to time estimation is either confused, or lying.
- darkr 8y ago
  Absolutely, story points are used as a component in the estimation of time. Story points on their own are useless though; they are an abstract thing that only means anything to the team and it’s velocity. A good analogy is that they are an estimate of distance. Knowing roughly how far something is away does not tell you how soon you will get there. You can only do this by working with an average of how fast the team can go. If the team is terrible at estimating distance, then the velocity will reflect that and gradually self-correct.
  - t0mbstone 8y ago
    Just because you swapped the word "time" with "distance" doesn't mean you aren't still talking about time. Distance from what? How far it is from now until when the work will be done. You are still talking about time. I feel that swapping out the term with one that is more vague is, at worst, disingenuous, and at best, counter-productive.
- bunderbunder 8y ago
  Story points are like BMI: They're meant to be accurate enough that, when you aggregate them over a whole bunch of items, you end up with a reasonably reliable time estimate. But they're a terrible measure of time to complete an individual task. They were never meant to be such a thing in the first place. That's why the canonical Scrum books always say that the PO can use story points to (roughly) estimate completion dates, but the development team should never use them to figure out how many items to accept into the next sprint.
wool_gather 8y ago
> If you're directly equating story points to time then you're doing it wrong. But it's not us, the developers, doing this conflation. It's management. No matter how many times we say "story points are useless without a consistent measurement of velocity", they still say "okay, but 2 + 5 + 3 + 2 = 12 dev days, so you and Jane can have ${FEATURE} done on Tuesday, right?"

by darkr 8y ago

t0mbstone 8y ago

And yet, story points are used to estimate how much work a team can get done in a sprint, which is a time measurement... and they are used to track velocity, which is used by management to figure out when a project might be completed (also a measurement of time). "Oh, story points are just about the complexity" Oh really? Why does complexity matter, if not to function as an indicator of how long something might take to finish? Anyone who is telling you that story points aren't directly related to time estimation is either confused, or lying.

darkr 8y ago
Absolutely, story points are used as a component in the estimation of time. Story points on their own are useless though; they are an abstract thing that only means anything to the team and it’s velocity. A good analogy is that they are an estimate of distance. Knowing roughly how far something is away does not tell you how soon you will get there. You can only do this by working with an average of how fast the team can go. If the team is terrible at estimating distance, then the velocity will reflect that and gradually self-correct.
- t0mbstone 8y ago
  Just because you swapped the word "time" with "distance" doesn't mean you aren't still talking about time. Distance from what? How far it is from now until when the work will be done. You are still talking about time. I feel that swapping out the term with one that is more vague is, at worst, disingenuous, and at best, counter-productive.
bunderbunder 8y ago
Story points are like BMI: They're meant to be accurate enough that, when you aggregate them over a whole bunch of items, you end up with a reasonably reliable time estimate. But they're a terrible measure of time to complete an individual task. They were never meant to be such a thing in the first place. That's why the canonical Scrum books always say that the PO can use story points to (roughly) estimate completion dates, but the development team should never use them to figure out how many items to accept into the next sprint.

wool_gather 8y ago

> If you're directly equating story points to time then you're doing it wrong. But it's not us, the developers, doing this conflation. It's management. No matter how many times we say "story points are useless without a consistent measurement of velocity", they still say "okay, but 2 + 5 + 3 + 2 = 12 dev days, so you and Jane can have ${FEATURE} done on Tuesday, right?"