4 ms·

Oh you want some kind of numerical estimation measure? <Rolls 1DFibonacci in his mind> It's a three. Have fun! --- Unless it's something I've actually impl

• sverhagen 3y ago
  A three is fine. (Or a two. Whatever you want it to be.) In fact, everything is a three. (Or a two.) If it's a five, or an eight, it just needs to be broken up further, until it's a three. (Or a two. You see, I don't care.) If you don't know yet how to break it up, you need a spike. A spike is... you guessed it, a three. (Or...) My point (pun intended), the points are for discussion, not for measurement.
  • sirsinsalot 3y ago
    This is correct. There's lots of people in here complaining with all the authority of experience when in fact, they're complaining that the ruler they're using to measure a mile is too small. Throw rulers in the bin! Down with measuring all together! Engineering needs risk management, accurate estimation and prediction, cost control and all the other things SWEs tend to thumb their nose at. If you think something is crap, chances are you're using it wrong or don't understand. Sadly software is filled with "smartest person in the room" types who think if they don't understand something, then it is clearly not them at fault! Pop your ego aside and ask. People like Sverhagen actually know what the tool should be used for. Sadly software isn't building a house, assembling a car or any other engineering task with very uniform and predictable discrete components ... so we need measures that deal with the ambiguity, complexity and attempt to measure inaccuracy accurately. Estimation with something like a fib sequence is designed to abstractly encapsulate the real-world impact of a task in terms of risk, effort, unpredictability, variability and so on. Odd that software engineers so adept at abstract reasoning can fail to see that this estimation method (like all of them) is a lossy encapsulation of many concerns. Sadly unsuprising that many offer no alternative, just complaints and bluster.
    • JohnFen 3y ago
      > Odd that software engineers so adept at abstract reasoning can fail to see that this estimation method (like all of them) is a lossy encapsulation of many concerns. I think most software engineers know this. In my experience, the problem is that management doesn't.
  • SkyPuncher 3y ago
    This is basically what we've come to. We don't force break down until 13. There are occasions where it's either (1) far easier to keep something as one, large piece (2) it's not really feasible to break down further. Ideally, most stories should be 3 or 5 pointers.
    • sverhagen 3y ago
      Even for a 5 I would encourage a discussion to see if it is worthwhile to be split up. Smaller stories lead to smaller code reviews, easier for the code reviewer, quicker updates in standup, no one falling behind. You can still decide to keep the occasional 5, but it's worth the discussion.
      • Falkon1313 3y ago
        That depends significantly on your team's measure of points. My team would never waste time trying to split a 5. But a 34, we would almost always try to split. 21s, we try to limit how many of them there are, but we're wary of splitting too much because splitting them up into, say, three separate 8s and then having to add a 13 to puzzle piece them all back together again isn't necessarily an improvement. But I think our points scale is quite different from what many other teams use. In any case, you have to be wary of splitting things too much (or not enough). If your 'bricks' are 8s, 13s, and 21s, then splitting a 5 is just making more work. But if your 'bricks' are 1s, 2s, and 3s, then splitting a 5 may well be a good idea.
        • SkyPuncher 3y ago
          It sounds like you're team has anchored around 13 as what we'd call our 5. Neither is right or wrong, just different.