4 ms·

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 t

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

by tra3 4y ago

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.