4 ms·

Gonna drop my pet conspiracy theory here and say that a Chinese person had to have come up with the asinine Fibonacci system everyone uses for estimation. Nobo

Gonna drop my pet conspiracy theory here and say that a Chinese person had to have come up with the asinine Fibonacci system everyone uses for estimation. Nobody ever uses anything above 5. If you do, you end up story splitting/slicing it until you have a bunch of <5’s. You’re left with an estimation system of 1, 2, 3, and 5. Four would be really fucking convenient to use but we can’t because of the system. Who superstitiously hates the number four more than anyone? The Chinese. I’m joking about the Chinese thing, of course, but the Fibonacci system really is stupid for estimation.

tra3 4y ago
It’s a cute shorthand. Like T-shirt sizing: small, medium, large. The point is that sizing is relative. That 2 point story kinda looks like it might be twice the work of that 1 point story. If your story is an 8 (or xxl) it’s likely to be underestimated due to hidden complexity. That’s why you should try to split it up. Although, it’s not like I haven’t had a bunch of “small” stories that ended up being triple-x large.
- wizofaus 4y ago
  Is there actually evidence that splitting up a big task reliably reduces the time it takes to complete? I've definitely seen cases where significant time has been spent trying to break up a story to avoid 8+ point monsters, but the result was a bunch of tasks so interdependent that any attempt to work on one inevitably ended up being held up by the need to complete others (or worse, two people end up doing the same thing). I'm pretty sure the orginal task could have been more efficiently handled by a single dev all in one go, and other unrelated tasks could have been taken on by other devs.
  - tra3 4y ago
    Great question. The only rigorous work on estimation I'm familiar with is Steve McConnell's "Software Estimation". It's been a while since I read it, but here's a paragraph from "estimating by analogy", kinda what we're talking about: > The basic approach that Mike is using in this example is estimation by analogy, which is the simple idea that you can create accurate estimates for a new project by comparing the new project to a similar past project. > I’ve had several hundred estimators create estimates for the Triad project. Using the approach implied in the example, their estimates have ranged from 30 to 144 staff months, with an average of 53 staff months. The standard deviation of their esti- mates is 24, or 46% of the average answer. That is not very good! A little bit of structure on the process helps a lot. and then later on story points: > On a numeric scale, the ratios between the numbers on the scale suggest that the underlying quantities being measured bear a proportionate relationship. If your story points scale is a Fibonacci sequence, a scale of 1, 2, 3, 5, 8, 13 suggests that a story of 5 points will take 5/3 as much effort as a story of 3 points. It suggests that a story of 13 points will take more than 4 times as much effort as a story of 3 points. > These relationships turn out to be a double-edged sword. If the necessary care is taken to ensure that stories classified as 13 points really are about 4 times as much effort as stories classified as 3 points, that’s great. That means you can compute an average effort per story point (as described earlier), multiply the total number of story points by the average, and get a meaningful result (also as described earlier). Accomplishing this level of accuracy requires that great discipline be exercised in assigning story points to stories. It also requires checking actual project data to ensure that the ratios that are estimated are the ratios actually found in practice. I've strayed from your question.. no I'm not aware of any evidence that this is actually worth doing. To me, the value is in trying to trying to decompose tasks and think about the consituent parts. McConnell expressly calls this out as being a double edged sword if you cannot do it properly though.
shoo 4y ago
If you truly embrace the fibonnaci system, the estimation system is 0, 1, 1, 2, 3, 5, ..., as defined in the standard https://oeis.org/A000045 https://oeis.org/A000045 . So if someone says they estimate "1", they should clarify if they mean the former one or the latter one. The former one is less likely to grow into a "2" or a "3" than the latter one, but it does risk growing into the latter "1".
fedeb95 4y ago
I've used it with my team for a couple of years and I don't really dislike it as long as people don't take it very seriously. It is mainly a tool to reason about what needs to be done. It's interesting when someone gives a 2 and someone gives an 8. Why 2? Why 8? Discussing about a thing makes it clearer what may be complications and things to be aware of. Honestly I don't care about the number themselves and probably three levels are enough and may well be orange, apple, banana.
ThePadawan 4y ago
I've worked on 21s before. It's my understanding that there are multiple theoretic reasons for using Fibonacci numbers: * The bigger they get, the further apart they are. That is helpful because estimating big things is less accurate than estimating small things. * If the estimate gets to big, the next step is to split the task. Humans tend to err towards splitting things 50/50 (? I don't have an actual source for that) so it's generally more helpful to split a task into a slightly smaller and a slightly bigger subtask. Fibonacci numbers make that very easy, and recursively possible.

tra3 4y ago

It’s a cute shorthand. Like T-shirt sizing: small, medium, large. The point is that sizing is relative. That 2 point story kinda looks like it might be twice the work of that 1 point story. If your story is an 8 (or xxl) it’s likely to be underestimated due to hidden complexity. That’s why you should try to split it up. Although, it’s not like I haven’t had a bunch of “small” stories that ended up being triple-x large.

wizofaus 4y ago
Is there actually evidence that splitting up a big task reliably reduces the time it takes to complete? I've definitely seen cases where significant time has been spent trying to break up a story to avoid 8+ point monsters, but the result was a bunch of tasks so interdependent that any attempt to work on one inevitably ended up being held up by the need to complete others (or worse, two people end up doing the same thing). I'm pretty sure the orginal task could have been more efficiently handled by a single dev all in one go, and other unrelated tasks could have been taken on by other devs.
- tra3 4y ago
  Great question. The only rigorous work on estimation I'm familiar with is Steve McConnell's "Software Estimation". It's been a while since I read it, but here's a paragraph from "estimating by analogy", kinda what we're talking about: > The basic approach that Mike is using in this example is estimation by analogy, which is the simple idea that you can create accurate estimates for a new project by comparing the new project to a similar past project. > I’ve had several hundred estimators create estimates for the Triad project. Using the approach implied in the example, their estimates have ranged from 30 to 144 staff months, with an average of 53 staff months. The standard deviation of their esti- mates is 24, or 46% of the average answer. That is not very good! A little bit of structure on the process helps a lot. and then later on story points: > On a numeric scale, the ratios between the numbers on the scale suggest that the underlying quantities being measured bear a proportionate relationship. If your story points scale is a Fibonacci sequence, a scale of 1, 2, 3, 5, 8, 13 suggests that a story of 5 points will take 5/3 as much effort as a story of 3 points. It suggests that a story of 13 points will take more than 4 times as much effort as a story of 3 points. > These relationships turn out to be a double-edged sword. If the necessary care is taken to ensure that stories classified as 13 points really are about 4 times as much effort as stories classified as 3 points, that’s great. That means you can compute an average effort per story point (as described earlier), multiply the total number of story points by the average, and get a meaningful result (also as described earlier). Accomplishing this level of accuracy requires that great discipline be exercised in assigning story points to stories. It also requires checking actual project data to ensure that the ratios that are estimated are the ratios actually found in practice. I've strayed from your question.. no I'm not aware of any evidence that this is actually worth doing. To me, the value is in trying to trying to decompose tasks and think about the consituent parts. McConnell expressly calls this out as being a double edged sword if you cannot do it properly though.

shoo 4y ago

If you truly embrace the fibonnaci system, the estimation system is 0, 1, 1, 2, 3, 5, ..., as defined in the standard https://oeis.org/A000045 https://oeis.org/A000045 . So if someone says they estimate "1", they should clarify if they mean the former one or the latter one. The former one is less likely to grow into a "2" or a "3" than the latter one, but it does risk growing into the latter "1".

fedeb95 4y ago

I've used it with my team for a couple of years and I don't really dislike it as long as people don't take it very seriously. It is mainly a tool to reason about what needs to be done. It's interesting when someone gives a 2 and someone gives an 8. Why 2? Why 8? Discussing about a thing makes it clearer what may be complications and things to be aware of. Honestly I don't care about the number themselves and probably three levels are enough and may well be orange, apple, banana.

ThePadawan 4y ago

I've worked on 21s before. It's my understanding that there are multiple theoretic reasons for using Fibonacci numbers: * The bigger they get, the further apart they are. That is helpful because estimating big things is less accurate than estimating small things. * If the estimate gets to big, the next step is to split the task. Humans tend to err towards splitting things 50/50 (? I don't have an actual source for that) so it's generally more helpful to split a task into a slightly smaller and a slightly bigger subtask. Fibonacci numbers make that very easy, and recursively possible.