4 ms·

It’s different because it can remove a bias out of estimations.

by konschubert 4y ago

SanderNL 4y ago
But eventually everyone knows that your gold stars stand for weeks. So how does this help?
- konschubert 4y ago
  Because you can keep tracking how long things actually take. And then divide by the gold stars, to see how much time you actually need for a golf star. And that number might change over time and that’s okay, and you can keep tracking it. It’s a bit of a mind trick. Instead of thinking: “How long will this ticket take?” you think: “Is this rather as complex as the 3 star tickets I did in the past, or is it as complex as the 5 star tickets? “ You estimate in terms of other tickets, not in terms of time. It helps to remove bias.
  - SanderNL 4y ago
    The only quasi-interesting property this has is that it can change over time. Nothing you said changes the main problem: gold stars are weeks and we all know it. Next year they are two weeks, fine.
    - bluefirebrand 4y ago
      "You said it would take a week" "No I said it was 12 jellybeans" "but we all know that 12 jellybeans is a week!!" "No, we all know that 12 jellybeans is explicitly not a week. It just happens that 12 jellybeans has taken 'around a week' in the past. An estimate of 12 jellybeans is still not a promise that it will only take a week."
      - chasd00 4y ago
        then "ok, well i'm not paying you until what i asked for is in production".
        bluefirebrand 4y ago
        Withholding salaries is a crime, so... I strongly doubt it.
    - Izkata 4y ago
      This mapping falls apart when the individual devs have different levels of experience. A gold star is a different unit of time per individual; Dev A might be able to complete 1 gold star in 1 week, but Dev B with less experience takes 2 weeks. The right thing to do isn't to estimate the average 1.5 weeks, since the case might not actually be done for another month, and it might end up actually being done by Dev C who just joined the team, for who 1 gold star is currently 3 or 4 weeks.
      - konschubert 4y ago
        A team has an average.
        willcipriano 4y ago
        If you took all the winning lottery numbers you could probably find a average as well.
        konschubert 4y ago
        This is a nonsensical response. An absolute non sequitur
    - ohthehugemanate 4y ago
      No, they are not weeks, and the minute "we all know it" you are fucked. Engineers are not concerned with time. They are concerned with feature completeness and quality. They do not care how long a task takes, only that it is done Right. When the PM asks how hard it is, that's their only consideration. The PM only cares about time to make accurate predictions for the rest of the business. A given task takes as long as it takes to be done Right. If the business wants it on a different timeline, the business has to redefine the task, or redefine Right (ie skipping tests or doco). Research bears it out: human brains suck at estimating time, and are much better as soon as you talk in terms of effort. BUT if you want to insist on brute forcing through our cognitive biases, I have good news: you can do almost as well by tracking the relationship between "developer time" and "real time". You're still dealing in abstracted units, of course, but you can still pretend you aren't, which is the important thing.
      - SanderNL 4y ago
        I get the sentiment, but ultimately business is time-bound. Everything is about time. But now we have a bunch of “engineers” (that somehow are fundamentally incapable of structured planning and execution) that are “not concerned with time”. I found your characterization of engineers and PMs not useful and a bit childish. This is not how money is made. Let’s just agree I don’t understand this. You sound well-informed and I’m just a simpleton.

It’s different because it can remove a bias out of estimations.

SanderNL 4y ago

But eventually everyone knows that your gold stars stand for weeks. So how does this help?

konschubert 4y ago
Because you can keep tracking how long things actually take. And then divide by the gold stars, to see how much time you actually need for a golf star. And that number might change over time and that’s okay, and you can keep tracking it. It’s a bit of a mind trick. Instead of thinking: “How long will this ticket take?” you think: “Is this rather as complex as the 3 star tickets I did in the past, or is it as complex as the 5 star tickets? “ You estimate in terms of other tickets, not in terms of time. It helps to remove bias.
- SanderNL 4y ago
  The only quasi-interesting property this has is that it can change over time. Nothing you said changes the main problem: gold stars are weeks and we all know it. Next year they are two weeks, fine.
  - bluefirebrand 4y ago
    "You said it would take a week" "No I said it was 12 jellybeans" "but we all know that 12 jellybeans is a week!!" "No, we all know that 12 jellybeans is explicitly not a week. It just happens that 12 jellybeans has taken 'around a week' in the past. An estimate of 12 jellybeans is still not a promise that it will only take a week."
    - chasd00 4y ago
      then "ok, well i'm not paying you until what i asked for is in production".
      - bluefirebrand 4y ago
        Withholding salaries is a crime, so... I strongly doubt it.
  - Izkata 4y ago
    This mapping falls apart when the individual devs have different levels of experience. A gold star is a different unit of time per individual; Dev A might be able to complete 1 gold star in 1 week, but Dev B with less experience takes 2 weeks. The right thing to do isn't to estimate the average 1.5 weeks, since the case might not actually be done for another month, and it might end up actually being done by Dev C who just joined the team, for who 1 gold star is currently 3 or 4 weeks.
    - konschubert 4y ago
      A team has an average.
      - willcipriano 4y ago
        If you took all the winning lottery numbers you could probably find a average as well.
        konschubert 4y ago
        This is a nonsensical response. An absolute non sequitur
  - ohthehugemanate 4y ago
    No, they are not weeks, and the minute "we all know it" you are fucked. Engineers are not concerned with time. They are concerned with feature completeness and quality. They do not care how long a task takes, only that it is done Right. When the PM asks how hard it is, that's their only consideration. The PM only cares about time to make accurate predictions for the rest of the business. A given task takes as long as it takes to be done Right. If the business wants it on a different timeline, the business has to redefine the task, or redefine Right (ie skipping tests or doco). Research bears it out: human brains suck at estimating time, and are much better as soon as you talk in terms of effort. BUT if you want to insist on brute forcing through our cognitive biases, I have good news: you can do almost as well by tracking the relationship between "developer time" and "real time". You're still dealing in abstracted units, of course, but you can still pretend you aren't, which is the important thing.
    - SanderNL 4y ago
      I get the sentiment, but ultimately business is time-bound. Everything is about time. But now we have a bunch of “engineers” (that somehow are fundamentally incapable of structured planning and execution) that are “not concerned with time”. I found your characterization of engineers and PMs not useful and a bit childish. This is not how money is made. Let’s just agree I don’t understand this. You sound well-informed and I’m just a simpleton.