6 ms·

I’ve never understood story points either. Somehow, the argument goes that if you take a process that involves an high level of uncertainty, and you replace cle

by dimal 4y ago

I’ve never understood story points either. Somehow, the argument goes that if you take a process that involves an high level of uncertainty, and you replace clearly defined units of work (time) with vaguely defined units of work (points), this will magically make estimation and planning _more_ accurate. Maybe, since you’re using Fibonnaci numbers, that makes it scientific?! I’ve never seen it actually work in fifteen years of trying.

dzikimarian 4y ago
Senior says task will take one day. Junior says it will take 3 days. What do you put into estimate? Story points are simply a way to say "I think that looks roughly like twice the work of that one we estimated before". Usefulness depends on specific environment and who and for what interprets the output (usually, at some organization level, there's excel/Gantt, that will convert them into an exact date. That will fail spectacularly in 99% of the cases).
- tbrownaw 4y ago
  > Senior says task will take one day. Junior says it will take 3 days. What do you put into estimate? Well, who's planning to do it?
  - dzikimarian 4y ago
    Depending on the team, number of tasks, size of task etc, answer to this ranges from: guy who does the estimate, to: whoever picks it first.
    - dimal 4y ago
      Which is almost always known at the time of estimation, in my experience. In the cases where it's not, then ok, points could make sense, but only as an interim step towards getting to a real time estimate once you know who is doing it. Having a vague point estimate could then be a useful indicator of "we don't really know yet".
      - dzikimarian 4y ago
        > Which is almost always known at the time of estimation, in my experience. In mine - not so much. Two dev team? Sure, you probably know. 6 dev team? Not so much. Estimation, then back to customer to decide if they'll eat the cost and decision 2 weeks later? Good luck knowing what will happen then. Point is answering question "does it fit into the sprint", knowing that usually you can fit 3 big tasks and 3-5 small. Then real time estimate is end of sprint.
- TulliusCicero 4y ago
  > "I think that looks roughly like twice the work of that one we estimated before". And by "twice the work" they mean takes twice as long. It's still time. Anyway you could just say "2 days of work" with the understanding that duh, a senior can do it quicker than a junior. It's just an estimate anyway.
  - dzikimarian 4y ago
    So basically you say "two days", while knowing that won't be two days - it's "virtual day". At this point how is it different from story point? :-) It's weird how people whose half of work is coming up with clever abstractions, have so much problem with that one.
    - woopwoop24 4y ago
      because everyone could have a different opinion on what it actually means instead of just a simple time based measurement. The whole thing is just absolute bonkers
      - dzikimarian 4y ago
        Well for a day I've already meet: ideal man/day, average man/day of the team, man/day of the guy doing estimate. Maybe estimation is complex thing and therefore team needs to align opinions before doing it?
        adammarples 4y ago
        We never do that though, we have to estimate our own tickets. So we're always estimating time for ourselves, we just can't say it's time though. Drives me mad but scrum masters these days have fully drunk the kool aid, it's fixed adherence to meaningless fibonacci story points or you're not doing it right.
    - TulliusCicero 4y ago
      You don't know that it won't be two days. It's an estimate, it's possible that a junior will go quick or senior will go slow. That's why points aren't really necessary. Using days is still an estimate. That said, I don't really object to points, I object to the idea that they don't represent time, when they obviously do.
- dimal 4y ago
  > Senior says task will take one day. Junior says it will take 3 days. What do you put into estimate? Who is doing the work? The senior? One day. The junior? Three days. The estimate should always be done by the person doing the work. This also forces people to have skin in the game when making estimates. When you have a full team coming up with points, then no one has any consequences for being wrong. But if you say one day, then you have some incentive to think things through. You want to live up to your commitment. Of course, this assumes that there are some consequences for being wrong, which usually isn't the case. I think this is where many people go wrong with time estimates. If you're repeatedly wrong, that's not because time estimates don't work. That's because you're bad at them. And like most skills, if you do them repeatedly and try to learn from the cases where you failed, you'll get better at it.

by dimal 4y ago

dzikimarian 4y ago

Senior says task will take one day. Junior says it will take 3 days. What do you put into estimate? Story points are simply a way to say "I think that looks roughly like twice the work of that one we estimated before". Usefulness depends on specific environment and who and for what interprets the output (usually, at some organization level, there's excel/Gantt, that will convert them into an exact date. That will fail spectacularly in 99% of the cases).

tbrownaw 4y ago
> Senior says task will take one day. Junior says it will take 3 days. What do you put into estimate? Well, who's planning to do it?
- dzikimarian 4y ago
  Depending on the team, number of tasks, size of task etc, answer to this ranges from: guy who does the estimate, to: whoever picks it first.
  - dimal 4y ago
    Which is almost always known at the time of estimation, in my experience. In the cases where it's not, then ok, points could make sense, but only as an interim step towards getting to a real time estimate once you know who is doing it. Having a vague point estimate could then be a useful indicator of "we don't really know yet".
    - dzikimarian 4y ago
      > Which is almost always known at the time of estimation, in my experience. In mine - not so much. Two dev team? Sure, you probably know. 6 dev team? Not so much. Estimation, then back to customer to decide if they'll eat the cost and decision 2 weeks later? Good luck knowing what will happen then. Point is answering question "does it fit into the sprint", knowing that usually you can fit 3 big tasks and 3-5 small. Then real time estimate is end of sprint.
TulliusCicero 4y ago
> "I think that looks roughly like twice the work of that one we estimated before". And by "twice the work" they mean takes twice as long. It's still time. Anyway you could just say "2 days of work" with the understanding that duh, a senior can do it quicker than a junior. It's just an estimate anyway.
- dzikimarian 4y ago
  So basically you say "two days", while knowing that won't be two days - it's "virtual day". At this point how is it different from story point? :-) It's weird how people whose half of work is coming up with clever abstractions, have so much problem with that one.
  - woopwoop24 4y ago
    because everyone could have a different opinion on what it actually means instead of just a simple time based measurement. The whole thing is just absolute bonkers
    - dzikimarian 4y ago
      Well for a day I've already meet: ideal man/day, average man/day of the team, man/day of the guy doing estimate. Maybe estimation is complex thing and therefore team needs to align opinions before doing it?
      - adammarples 4y ago
        We never do that though, we have to estimate our own tickets. So we're always estimating time for ourselves, we just can't say it's time though. Drives me mad but scrum masters these days have fully drunk the kool aid, it's fixed adherence to meaningless fibonacci story points or you're not doing it right.
  - TulliusCicero 4y ago
    You don't know that it won't be two days. It's an estimate, it's possible that a junior will go quick or senior will go slow. That's why points aren't really necessary. Using days is still an estimate. That said, I don't really object to points, I object to the idea that they don't represent time, when they obviously do.
dimal 4y ago
> Senior says task will take one day. Junior says it will take 3 days. What do you put into estimate? Who is doing the work? The senior? One day. The junior? Three days. The estimate should always be done by the person doing the work. This also forces people to have skin in the game when making estimates. When you have a full team coming up with points, then no one has any consequences for being wrong. But if you say one day, then you have some incentive to think things through. You want to live up to your commitment. Of course, this assumes that there are some consequences for being wrong, which usually isn't the case. I think this is where many people go wrong with time estimates. If you're repeatedly wrong, that's not because time estimates don't work. That's because you're bad at them. And like most skills, if you do them repeatedly and try to learn from the cases where you failed, you'll get better at it.