7 ms·

I believe this is the reason why scrum uses story points instead of time estimate. By putting uncertainty on the same level as effort, you give it more weight.

I believe this is the reason why scrum uses story points instead of time estimate. By putting uncertainty on the same level as effort, you give it more weight. And using a fibonacci sequence rather than a continuous amount with the rule you should round up if unsure tend to correct those defects.

js8 8y ago
Yeah, that's the same reason to use pseudoscience, it's a longer word with "science" in it, which means - more science!
IshKebab 8y ago
Yeah in my experience everyone just mentally translates to time anyway so it is pointless. "11 points, that's about 2 days right?" If you want to make the uncertainty clear it's better to allow ranges, like 2h-5d instead of trying to play stupid mind games. Story points are like setting your watch 5 mins early so you are on time to things. It doesn't work.
- ricardobeat 8y ago
  That happens indeed, but the point (!) stands: the fibonacci scale ensures estimates are rounded up, and that small abstraction merges time and complexity into a single number, whereas it feels more difficult to bump a time estimate based on unknowns/complexity.
- GrumpyNl 8y ago
  That's what happens, its all tranlated to hours and cost instantly. I have seen that at several places during poker sessions. The fun starts when management hears this and starts to calculate with it.
jfoutz 8y ago
there is an uncharitable response to this thread, which is marked dead. I do think there is a kernel of truth in that response, which is nothing more than mocking. why fibonacci? I think it's reasonable to say time includes an exponential error. an estimated 1 hour task is very different than an estimated 1 week task. i see that 1 hour, 1 day and 1 week estimates are progressively, and likely exponentially, worse. Is it just the ease of doing the math? (totally reasonable answer, in my humble opinion). or is there something specific about fibonacci that's actually relevant? I think it's the former not the latter. but if you have any evidence to the contrary, i'd love to hear it.
- js8 8y ago
  The kernel of truth of that response is that you won't get more certainty about an estimate by adding more uncertainty, no matter in how much pseudo-scientific cargo-culting mumbo-jumbo you cloak it. (Unfortunately, HN readers don't really like sarcastic commentary which requires reader to think it through. Time is precious, and we just want to be coddled, give me your opinion ELI8 straight, because there is no time to think!)
  - jfoutz 8y ago
    I think you're half right. adding an error band to a far out estimate won't give you a better estimate, but it might help tell you how much you _don't know_ about what you're facing. Cumulative error is _hard_. see weather prediction.
- tumetab1 8y ago
  The reason the Fibonacci sequence is used is because we don't think in an incremental scale but in a logarithm scale. In other words, we think that some simple takes 1 day, a more complex takes 3 and a even more complex takes 5 days. Usually we don't jump from 1 to 2 days when thinking about a task effort.
  - js8 8y ago
    You could have also used approximately logarithmic scale that everybody is familiar with, namely, cash! You know, 1,2,5,10,20,50,100,200,500.. But no, here we are doing science, that's why we use Fibonacci, hey even plants and rabbits are using it.
    - jfoutz 8y ago
      I kinda want to grab you by the lapels and re-enact that part from Clear and Present Danger. It doesn't matter what's true, it matters what i can prove! Unfortunately, the phrasing would be more like, It doesn't matter what's true, it matters what i can sell to management. In the absence of evidence to the contrary, i think i'm ready to take a side close to yours. It's useful to expand error bars exponentially as you move away from the time of the estimate, but there's nothing special about fibonacci.
StreamBright 8y ago
It is very easy to answer. Different people have different efficiency, therefore, a task completion does not depend solely on its complexity but also on who is executing it. You should think about it (even though there are no actual physical units you can use to make this work): Time to deliver a task = complexity / developer efficiency This is why it is hard to develop a method to estimate time for development tasks.
brianpgordon 8y ago
If regular time estimation has tricky statistical properties when combining multiple estimates, story point estimation is just hopeless. Especially on a Fibonacci scale. When estimating, nobody thinks that an 8-point story is the same as eight 1-point stories. Even the metric itself is nonlinear!
jon-wood 8y ago
I push back pretty hard on story points whenever I see them. They’re not useful until several iterations in, once you have a baseline for how many points can be delivered in an iteration, and even then one developer’s 1 point story is another’s 5 point. When estimating I tend to use a coarse scale of hours, days, weeks, and (in extreme cases) months. All estimates then get turned into a range between the minimum and maximum the estimate could mean - for example hours becomes 1 hour to 8 hours, days becomes 1 day to 5 days, and so on. Anything estimated as weeks or months probably needs scoping until it can be broken down into tasks that will take between an hour and a week. I find this method works well because it’s intuitive, comes out with a suitable amount of uncertainty relative to the size of the task, and finally results in estimates with units that are useful to project managers and the wider business in scheduling other work needed to get a feature into production.

js8 8y ago

Yeah, that's the same reason to use pseudoscience, it's a longer word with "science" in it, which means - more science!

IshKebab 8y ago

Yeah in my experience everyone just mentally translates to time anyway so it is pointless. "11 points, that's about 2 days right?" If you want to make the uncertainty clear it's better to allow ranges, like 2h-5d instead of trying to play stupid mind games. Story points are like setting your watch 5 mins early so you are on time to things. It doesn't work.

ricardobeat 8y ago
That happens indeed, but the point (!) stands: the fibonacci scale ensures estimates are rounded up, and that small abstraction merges time and complexity into a single number, whereas it feels more difficult to bump a time estimate based on unknowns/complexity.
GrumpyNl 8y ago
That's what happens, its all tranlated to hours and cost instantly. I have seen that at several places during poker sessions. The fun starts when management hears this and starts to calculate with it.

jfoutz 8y ago

there is an uncharitable response to this thread, which is marked dead. I do think there is a kernel of truth in that response, which is nothing more than mocking. why fibonacci? I think it's reasonable to say time includes an exponential error. an estimated 1 hour task is very different than an estimated 1 week task. i see that 1 hour, 1 day and 1 week estimates are progressively, and likely exponentially, worse. Is it just the ease of doing the math? (totally reasonable answer, in my humble opinion). or is there something specific about fibonacci that's actually relevant? I think it's the former not the latter. but if you have any evidence to the contrary, i'd love to hear it.

js8 8y ago
The kernel of truth of that response is that you won't get more certainty about an estimate by adding more uncertainty, no matter in how much pseudo-scientific cargo-culting mumbo-jumbo you cloak it. (Unfortunately, HN readers don't really like sarcastic commentary which requires reader to think it through. Time is precious, and we just want to be coddled, give me your opinion ELI8 straight, because there is no time to think!)
- jfoutz 8y ago
  I think you're half right. adding an error band to a far out estimate won't give you a better estimate, but it might help tell you how much you _don't know_ about what you're facing. Cumulative error is _hard_. see weather prediction.
tumetab1 8y ago
The reason the Fibonacci sequence is used is because we don't think in an incremental scale but in a logarithm scale. In other words, we think that some simple takes 1 day, a more complex takes 3 and a even more complex takes 5 days. Usually we don't jump from 1 to 2 days when thinking about a task effort.
- js8 8y ago
  You could have also used approximately logarithmic scale that everybody is familiar with, namely, cash! You know, 1,2,5,10,20,50,100,200,500.. But no, here we are doing science, that's why we use Fibonacci, hey even plants and rabbits are using it.
  - jfoutz 8y ago
    I kinda want to grab you by the lapels and re-enact that part from Clear and Present Danger. It doesn't matter what's true, it matters what i can prove! Unfortunately, the phrasing would be more like, It doesn't matter what's true, it matters what i can sell to management. In the absence of evidence to the contrary, i think i'm ready to take a side close to yours. It's useful to expand error bars exponentially as you move away from the time of the estimate, but there's nothing special about fibonacci.

StreamBright 8y ago

It is very easy to answer. Different people have different efficiency, therefore, a task completion does not depend solely on its complexity but also on who is executing it. You should think about it (even though there are no actual physical units you can use to make this work): Time to deliver a task = complexity / developer efficiency This is why it is hard to develop a method to estimate time for development tasks.

brianpgordon 8y ago

If regular time estimation has tricky statistical properties when combining multiple estimates, story point estimation is just hopeless. Especially on a Fibonacci scale. When estimating, nobody thinks that an 8-point story is the same as eight 1-point stories. Even the metric itself is nonlinear!

jon-wood 8y ago

I push back pretty hard on story points whenever I see them. They’re not useful until several iterations in, once you have a baseline for how many points can be delivered in an iteration, and even then one developer’s 1 point story is another’s 5 point. When estimating I tend to use a coarse scale of hours, days, weeks, and (in extreme cases) months. All estimates then get turned into a range between the minimum and maximum the estimate could mean - for example hours becomes 1 hour to 8 hours, days becomes 1 day to 5 days, and so on. Anything estimated as weeks or months probably needs scoping until it can be broken down into tasks that will take between an hour and a week. I find this method works well because it’s intuitive, comes out with a suitable amount of uncertainty relative to the size of the task, and finally results in estimates with units that are useful to project managers and the wider business in scheduling other work needed to get a feature into production.