5 ms·

So your team does basically, let’s say, 10 gold stars a week. Your epic and VeryNecessaryFeature(c) takes 30 gold stars. Pointy hair boss: this takes 3 weeks.

So your team does basically, let’s say, 10 gold stars a week. Your epic and VeryNecessaryFeature(c) takes 30 gold stars. Pointy hair boss: this takes 3 weeks. (and make it 2) How is this different from skipping the proxy and just using time directly?

tbrake 3y ago
The answer is not having a PHB. No non-unit-of-time estimation system will matter if there isn't buy-in from all levels. If the Directors/VPs/C-Suite etc view development in assembly line terms, then Xpoints = Ytime can never be avoided and yes, it just becomes an exercise in frustration. To date I haven't found a good antidote other than avoiding workplaces that view estimations as exactimations of time.
- Ensorceled 3y ago
  Ah, so the best way to provide time estimates so that the rest of the business can do planning is to not work at a business that needs to do planning.
  - tbrake 3y ago
    On a story by story basis saying points=time is an idea as silly as your deliberate misinterpretation of my post, yes.
konschubert 3y ago
It’s different because it can remove a bias out of estimations.
- SanderNL 3y ago
  But eventually everyone knows that your gold stars stand for weeks. So how does this help?
  - konschubert 3y 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 3y 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 3y 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 3y ago
        then "ok, well i'm not paying you until what i asked for is in production".
        bluefirebrand 3y ago
        Withholding salaries is a crime, so... I strongly doubt it.
      - Izkata 3y 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.
ohthehugemanate 3y ago
The problem in your story is a non technical boss making time estimates/demands. If that's gonna happen, the developers shouldn't bother with estimates at all because no one is listening. They can just go on missing the boss's fantasyland deadlines and save themselves the trouble. If the boss wants to know how long things will take, they have to ask the engineering teams. And the most accurate way for an engineering team to answer is with a track record of abstracted unit estimations and how long they took, to predict how long the abstracted unit estimation in question will take. And when the PHB says "make it two", the engineers can only reply "ok, tell us what features or standards to cut." No different than wiring a house: we can finish faster if you choose some rooms to skip, or some safety standards to skip. But those are the boss's decisions, not the engineers. BTW I agree with the responder who says quit from those environments ASAP. I don't know how engineers can overcome a dysfunctional business lead like that... and that kind of business lead is often an expert at making sure the repercussions land on someone else. Case in point, by asking you to finish faster he is tacitly asking you to skip capabilities or safety checks... and that way you're responsible for the fallout.

tbrake 3y ago

The answer is not having a PHB. No non-unit-of-time estimation system will matter if there isn't buy-in from all levels. If the Directors/VPs/C-Suite etc view development in assembly line terms, then Xpoints = Ytime can never be avoided and yes, it just becomes an exercise in frustration. To date I haven't found a good antidote other than avoiding workplaces that view estimations as exactimations of time.

Ensorceled 3y ago
Ah, so the best way to provide time estimates so that the rest of the business can do planning is to not work at a business that needs to do planning.
- tbrake 3y ago
  On a story by story basis saying points=time is an idea as silly as your deliberate misinterpretation of my post, yes.

konschubert 3y ago

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

SanderNL 3y ago
But eventually everyone knows that your gold stars stand for weeks. So how does this help?
- konschubert 3y 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 3y 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 3y 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 3y ago
        then "ok, well i'm not paying you until what i asked for is in production".
        bluefirebrand 3y ago
        Withholding salaries is a crime, so... I strongly doubt it.
    - Izkata 3y 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.

ohthehugemanate 3y ago

The problem in your story is a non technical boss making time estimates/demands. If that's gonna happen, the developers shouldn't bother with estimates at all because no one is listening. They can just go on missing the boss's fantasyland deadlines and save themselves the trouble. If the boss wants to know how long things will take, they have to ask the engineering teams. And the most accurate way for an engineering team to answer is with a track record of abstracted unit estimations and how long they took, to predict how long the abstracted unit estimation in question will take. And when the PHB says "make it two", the engineers can only reply "ok, tell us what features or standards to cut." No different than wiring a house: we can finish faster if you choose some rooms to skip, or some safety standards to skip. But those are the boss's decisions, not the engineers. BTW I agree with the responder who says quit from those environments ASAP. I don't know how engineers can overcome a dysfunctional business lead like that... and that kind of business lead is often an expert at making sure the repercussions land on someone else. Case in point, by asking you to finish faster he is tacitly asking you to skip capabilities or safety checks... and that way you're responsible for the fallout.