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.