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

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.

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?

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”

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.

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.

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).

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!

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.)

The problem with Agile induced "right sizing" of tasks is that you artificially split atomic units of work into multiple tickets.

A single deliverable is now 3-5 different tickets that might get split across sprints. It now becomes harder to express when a piece of atomic functionality will be delivered because you need to track with dependencies across the tickets, etc.

So it feels like contortions to make reality fit into Agile which negatively effect reality.

Let's say we are using Agile in the kitchen and we have 3 tickets - 1) research recipe, 2) collect ingredients, 3) bake cake. These are logical and understandable to a stakeholder. You can assign them different story points / sizes / durations / whatever. It's relatively easy to express the dependency and also keep it in your mental model. Each has a deliverable - 1) recipe & ingredient list 2) the ingredients 3) the cake.

However Big Agile Coach argues that really it should be 1a) research recipe, 1b) collate ingredients required, 2a) research pricing on ingredients 2b) create per-vendor ingredient lists 2c1) buy ingredients at vendor 1, 2c2) buy ingredients at vendor 2, 3a) clean kitchen 3b) prepare cake batter 3c) bake cake 3d) cake frosting/finishing

OK which of these 9 tickets depend on which / which can be parallelized / which are best to keep with a single dev, which should be done within a single sprint vs split across? Etc.

> "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?