4 ms·

If they're not time, why use numbers? Use fruits: easy peasy, it's a lemon. A really tough story, a coconut. You can't add them in any case, because they're not

If they're not time, why use numbers? Use fruits: easy peasy, it's a lemon. A really tough story, a coconut. You can't add them in any case, because they're not time.

ozim 2y ago
That is one of the complications - one thinks developers should be smart as in abstract thinking so they should understand (just like all the other numbers humanity made up): "numbers we call story points are not having property to add them and they are not convertible to time". *Properties of Whole Numbers: Whole numbers are closed under addition and multiplication. Zero is the additive identity element of the whole numbers. 1 is the multiplicative identity element. It obeys the commutative and associative property of addition and multiplication. It satisfies the distributive property of multiplication over addition and vice versa. *
- recursive 2y ago
  Why use a measure that creates this footgun? Why should our task estimation require this much abstract thinking? Why not invent the measure so that it's not misleading? Numbers generally have well-understood properties. Using them in a way where the properties don't apply is asking to be misunderstood.
- Viliam1234 2y ago
  And this is how the entire math gets done in 5 simple JIRA tasks. :D
1xdevnet 2y ago
I like this, I'd advocate for a fruit-based task system - although I suppose the exact fruit ranking would depend on the team. - easy peasy: lemon - easy but needs careful handling: kiwi - regular but boring: red delicious - regular, who wouldn't want to take one of these?: mango - large task, risk of splash damage if mishandled: watermelon - tough to crack, needs time or a hammer: coconut - technically we'll do this, but not really our job: tomato Edit: I am sad that emojis aren't allowed in comments, though it's understandable.
icedchai 2y ago
If you try this (and I have, just not with fruits), someone will complain they can't graph fruits. You'll tell them that's the point. They won't listen, so they'll map fruits to numbers, and now you have the same problem anyway. My personal preference is to use time estimates with some uncertainty. A day or less. 2-3 days. A week at most.
- wolpoli 2y ago
  > My personal preference is to use time estimates with some uncertainty. A day or less. 2-3 days. A week at most. In the project management world, there is an assumption that tasks that are overestimated and underestimated would even themselves out so that the total estimate would equal the actual time needed. Sad to say that accuracy of estimates don't follow normal distribution in software development.
  - SoftTalker 2y ago
    I had one manager who used time in orders of magnitude. He’d ask, “is it a day, a week, a month, or a year?”
    - jon-wood 2y ago
      I've done exactly this in the past, and then when someone asks how long the project as a whole is going to take it's easy enough to give a range. If someone says a task is going to take hours that's a range of 1-6 hours, if they say it's months that's 1-12 months. If you want more certainty in your estimate then you're going to have to give us some time to break things down.
vannevar 2y ago
Just because they're not time, doesn't mean you don't want to add them. Imagine you have an empty basket, and you're not sure how much fruit you can toss in it. So the first time, you just start tossing stuff in until it's full. The exact number of lemons, coconuts, etc will vary. But after a few rounds, you'll get a feel for how much of each you can get into the basket. That's story points. You feel your way into a groove where the team gets a more concrete sense about how much it can get done in a sprint, given the variability of the work, external projects/distractions, and the makeup of the team. Story points get a bad rap because a lot of engineering managers don't get scrum and just see a convenient way to measure productivity. Which story points are absolutely not meant to do, outside of the team itself setting its own sprint goals.
- tsimionescu 2y ago
  My experience is that story points get a bad rep because they don't mean anything unless you use them as an explicit proxy for time. There's no way to say in reality "this task is small" unless you have some idea of how long it takes. Additonally, this concept of velocity makes no sense because a task that's big for me might be small for someone else in the team, so then we either pre-assign tasks and set points based on assignment (and then have problems if we switch the assignee for any reason), or we assign "generic points" and that ends up not meaning anything at all if the team is not very uniform (e.g. all seniors with similar skills and ownership of most of the same code, or all juniors). Additonally, all methodologies tend to discourage correcting point values after the fact. That makes the process of deriving time estimates (velocity) even more error prone, because it conflates uncertainty with mistakes. That is, you can correctly estimate a task at 8 points and finish it in four weeks; or you can incorrectly estimate a task as 3 points and finish it in 4 weeks. That doesn't mean that the team has a velocity of about 1.35 points/week, it means it has a velocity of about 2 points/week, but made a mistake with one task.
  - vannevar 2y ago
    >My experience is that story points get a bad rep because they don't mean anything unless you use them as an explicit proxy for time. So when you shop for clothes, Small/Medium/Large are useless? You require precise measurements for every item, and they have to be exactly the same size across manufacturers, or else sizes have no utility for you? The reality is that a Large can be large on you in different ways, even if it's a t-shirt. And software complexity has a lot more dimensions than a t-shirt. The utility of story points is that they allow a team to create a rough idea of their capacity over a sprint, so that they don't consistently under- (or more commonly) over-commit. If you try to use story points purely as a uniform proxy for time, of course they're going to be useless, because you can always just use time instead.
candiddevmike 2y ago
I use Halo difficulty levels: Easy, Normal, Heroic, Legendary.

If they're not time, why use numbers? Use fruits: easy peasy, it's a lemon. A really tough story, a coconut. You can't add them in any case, because they're not time.

ozim 2y ago

That is one of the complications - one thinks developers should be smart as in abstract thinking so they should understand (just like all the other numbers humanity made up): "numbers we call story points are not having property to add them and they are not convertible to time". *Properties of Whole Numbers: Whole numbers are closed under addition and multiplication. Zero is the additive identity element of the whole numbers. 1 is the multiplicative identity element. It obeys the commutative and associative property of addition and multiplication. It satisfies the distributive property of multiplication over addition and vice versa. *

recursive 2y ago
Why use a measure that creates this footgun? Why should our task estimation require this much abstract thinking? Why not invent the measure so that it's not misleading? Numbers generally have well-understood properties. Using them in a way where the properties don't apply is asking to be misunderstood.
Viliam1234 2y ago
And this is how the entire math gets done in 5 simple JIRA tasks. :D

1xdevnet 2y ago

I like this, I'd advocate for a fruit-based task system - although I suppose the exact fruit ranking would depend on the team. - easy peasy: lemon - easy but needs careful handling: kiwi - regular but boring: red delicious - regular, who wouldn't want to take one of these?: mango - large task, risk of splash damage if mishandled: watermelon - tough to crack, needs time or a hammer: coconut - technically we'll do this, but not really our job: tomato Edit: I am sad that emojis aren't allowed in comments, though it's understandable.

icedchai 2y ago

If you try this (and I have, just not with fruits), someone will complain they can't graph fruits. You'll tell them that's the point. They won't listen, so they'll map fruits to numbers, and now you have the same problem anyway. My personal preference is to use time estimates with some uncertainty. A day or less. 2-3 days. A week at most.

wolpoli 2y ago
> My personal preference is to use time estimates with some uncertainty. A day or less. 2-3 days. A week at most. In the project management world, there is an assumption that tasks that are overestimated and underestimated would even themselves out so that the total estimate would equal the actual time needed. Sad to say that accuracy of estimates don't follow normal distribution in software development.
- SoftTalker 2y ago
  I had one manager who used time in orders of magnitude. He’d ask, “is it a day, a week, a month, or a year?”
  - jon-wood 2y ago
    I've done exactly this in the past, and then when someone asks how long the project as a whole is going to take it's easy enough to give a range. If someone says a task is going to take hours that's a range of 1-6 hours, if they say it's months that's 1-12 months. If you want more certainty in your estimate then you're going to have to give us some time to break things down.

vannevar 2y ago

Just because they're not time, doesn't mean you don't want to add them. Imagine you have an empty basket, and you're not sure how much fruit you can toss in it. So the first time, you just start tossing stuff in until it's full. The exact number of lemons, coconuts, etc will vary. But after a few rounds, you'll get a feel for how much of each you can get into the basket. That's story points. You feel your way into a groove where the team gets a more concrete sense about how much it can get done in a sprint, given the variability of the work, external projects/distractions, and the makeup of the team. Story points get a bad rap because a lot of engineering managers don't get scrum and just see a convenient way to measure productivity. Which story points are absolutely not meant to do, outside of the team itself setting its own sprint goals.

tsimionescu 2y ago
My experience is that story points get a bad rep because they don't mean anything unless you use them as an explicit proxy for time. There's no way to say in reality "this task is small" unless you have some idea of how long it takes. Additonally, this concept of velocity makes no sense because a task that's big for me might be small for someone else in the team, so then we either pre-assign tasks and set points based on assignment (and then have problems if we switch the assignee for any reason), or we assign "generic points" and that ends up not meaning anything at all if the team is not very uniform (e.g. all seniors with similar skills and ownership of most of the same code, or all juniors). Additonally, all methodologies tend to discourage correcting point values after the fact. That makes the process of deriving time estimates (velocity) even more error prone, because it conflates uncertainty with mistakes. That is, you can correctly estimate a task at 8 points and finish it in four weeks; or you can incorrectly estimate a task as 3 points and finish it in 4 weeks. That doesn't mean that the team has a velocity of about 1.35 points/week, it means it has a velocity of about 2 points/week, but made a mistake with one task.
- vannevar 2y ago
  >My experience is that story points get a bad rep because they don't mean anything unless you use them as an explicit proxy for time. So when you shop for clothes, Small/Medium/Large are useless? You require precise measurements for every item, and they have to be exactly the same size across manufacturers, or else sizes have no utility for you? The reality is that a Large can be large on you in different ways, even if it's a t-shirt. And software complexity has a lot more dimensions than a t-shirt. The utility of story points is that they allow a team to create a rough idea of their capacity over a sprint, so that they don't consistently under- (or more commonly) over-commit. If you try to use story points purely as a uniform proxy for time, of course they're going to be useless, because you can always just use time instead.

candiddevmike 2y ago

I use Halo difficulty levels: Easy, Normal, Heroic, Legendary.