3 ms·

"POINTS AREN'T TIME! THEY'RE EFFORT AND/OR COMPLEXITY!" I've been routinely told. Yet... low complexity stuff was expected to take less time, even if it was h

"POINTS AREN'T TIME! THEY'RE EFFORT AND/OR COMPLEXITY!" I've been routinely told. Yet... low complexity stuff was expected to take less time, even if it was high effort. All 'in my experience' of course. Changing 95 files because someone didn't want to centralize some value in a method call last year (YAGNI!) is now high effort, even if low complexity. Then... "that's too many files in a PR! break it up! no one can review that many files!" It's the same two line change in each file - this shouldn't take that long to 'review'. I've often spent more time arguing about points/effort/estimates than doing the low effort work. But if we don't record it properly, you won't get 'credit' for the work! Slow-paced insanity when taken anywhere near close to its logical conclusions.

peteradio 3y ago
Haha after 5 years our scrumlord finally relented that 1 point was 8 hours for our team because even he was apparently getting tired of the cognitive dissonance.
candiddevmike 3y ago
I love hearing "points aren't time but you can think of them like days"
- ed_elliott_asc 3y ago
  My response to estimating is that if you want anything accurate I’ll need time to estimate - roughly 1/4 of the estimated work should be spent estimating. As a rule of thumb, if the work is estimated to be a day then is should take me 1/4 day to estimate. If two days then half a day to estimate. If 4 weeks then 1 week to estimate. We normally continue with guesses that are meaningless.
  - bee_rider 3y ago
    What would you do if they actually gave you a week to come up with an estimate? Start drawing Gantt charts? 1/4 seems reasonable for a day or two, but I dunno… it seems like there must be some constant factor?
    - ed_elliott_asc 3y ago
      I’d draw a lot and probably prototype as well - I suppose the main thing is that we never get to that as we estimate but don’t do “big design upfront”
steveBK123 3y ago
Also don't forget story point Goldilocks. We don't create 1 point stories, you need to roll this up with another story! Hey we don't do 13 point stories, you need to break that one up! 8 points? you sure that isn't a 5? 2 points, 3 points.. what's the difference just mark it as a 2. OK so basically we just have 2s & 5s then? Amazing.
- lowercased 3y ago
  I had a colleague who told me his secret - "I just say 3 or 5 to anything". That was it. He would pause, then say 3 or 5. Anything I was asked to estimate, I'd give real effort estimates based on their scale. And was always pushed back on like you noted above. And it was a constant struggle. Yet... I always (like... over 95% of the time) hit all my targets, delivered early, and would sometimes pick up the other slack. The other guy with 3/5 - would almost always get pulled in to some other project (or aspect of the project) so almost never got his stuff 'done' (often I would finish it). But on paper... his estimates were always 'so easy' and his tickets always got done (often by me) but I was the 'difficult' one (for many other reasons beyond this).
  - steveBK123 3y ago
    Ah yes, but remember "we don't measure individual velocity!". So all that gets remembered is .. this guy always argues in the scrum meetings, AND his estimates are always high, smdh!
- cpeterso 3y ago
  If you try to right size tasks, you can just count tasks instead of estimating them. This approach even has a catchy brand name in agile circles: #noestimates. In every team I’ve tracked, the task count burndown velocity was impressively linear, whether looking at weeks, months, or years of data. I think we can thank the Law of Large Numbers, with shorter than average and longer than average tasks balancing each other over time. (We never bothered with story points, so I can’t compare.)
  - steveBK123 3y ago
cassianoleal 3y ago
> "POINTS AREN'T TIME! THEY'RE EFFORT AND/OR COMPLEXITY!" I've been routinely told. Yet... low complexity stuff was expected to take less time, even if it was high effort. All 'in my experience' of course. This realy grinds my gears. I had a recent experience with a scrum master (technically a delivery lead but in practice a scrum master). Really nice guy, smart, easy going. We had many discussions about the value of estimates, and the whole "it's complexity, not time" trope would come up. So I asked what the estimates were used for. Turns out they're used to forecast cadence / velocity. Of course, knowing that we were going to be asked why a small story was taking two weeks to complete, we'd start sizing based on time. After all, we're humans, biased and flawed. Now you tell me, how do you want a measure of complexity to be a predictor for cadence when these 2 things are at best orthogonal?

peteradio 3y ago

Haha after 5 years our scrumlord finally relented that 1 point was 8 hours for our team because even he was apparently getting tired of the cognitive dissonance.

candiddevmike 3y ago

I love hearing "points aren't time but you can think of them like days"

ed_elliott_asc 3y ago
My response to estimating is that if you want anything accurate I’ll need time to estimate - roughly 1/4 of the estimated work should be spent estimating. As a rule of thumb, if the work is estimated to be a day then is should take me 1/4 day to estimate. If two days then half a day to estimate. If 4 weeks then 1 week to estimate. We normally continue with guesses that are meaningless.
- bee_rider 3y ago
  What would you do if they actually gave you a week to come up with an estimate? Start drawing Gantt charts? 1/4 seems reasonable for a day or two, but I dunno… it seems like there must be some constant factor?
  - ed_elliott_asc 3y ago
    I’d draw a lot and probably prototype as well - I suppose the main thing is that we never get to that as we estimate but don’t do “big design upfront”

steveBK123 3y ago

Also don't forget story point Goldilocks. We don't create 1 point stories, you need to roll this up with another story! Hey we don't do 13 point stories, you need to break that one up! 8 points? you sure that isn't a 5? 2 points, 3 points.. what's the difference just mark it as a 2. OK so basically we just have 2s & 5s then? Amazing.

lowercased 3y ago
I had a colleague who told me his secret - "I just say 3 or 5 to anything". That was it. He would pause, then say 3 or 5. Anything I was asked to estimate, I'd give real effort estimates based on their scale. And was always pushed back on like you noted above. And it was a constant struggle. Yet... I always (like... over 95% of the time) hit all my targets, delivered early, and would sometimes pick up the other slack. The other guy with 3/5 - would almost always get pulled in to some other project (or aspect of the project) so almost never got his stuff 'done' (often I would finish it). But on paper... his estimates were always 'so easy' and his tickets always got done (often by me) but I was the 'difficult' one (for many other reasons beyond this).
- steveBK123 3y ago
  Ah yes, but remember "we don't measure individual velocity!". So all that gets remembered is .. this guy always argues in the scrum meetings, AND his estimates are always high, smdh!
cpeterso 3y ago
If you try to right size tasks, you can just count tasks instead of estimating them. This approach even has a catchy brand name in agile circles: #noestimates. In every team I’ve tracked, the task count burndown velocity was impressively linear, whether looking at weeks, months, or years of data. I think we can thank the Law of Large Numbers, with shorter than average and longer than average tasks balancing each other over time. (We never bothered with story points, so I can’t compare.)
- steveBK123 3y ago

cassianoleal 3y ago

> "POINTS AREN'T TIME! THEY'RE EFFORT AND/OR COMPLEXITY!" I've been routinely told. Yet... low complexity stuff was expected to take less time, even if it was high effort. All 'in my experience' of course. This realy grinds my gears. I had a recent experience with a scrum master (technically a delivery lead but in practice a scrum master). Really nice guy, smart, easy going. We had many discussions about the value of estimates, and the whole "it's complexity, not time" trope would come up. So I asked what the estimates were used for. Turns out they're used to forecast cadence / velocity. Of course, knowing that we were going to be asked why a small story was taking two weeks to complete, we'd start sizing based on time. After all, we're humans, biased and flawed. Now you tell me, how do you want a measure of complexity to be a predictor for cadence when these 2 things are at best orthogonal?