But still we are much better at estimating complexity
Time estimations usually tends to be overly optimistic. I don’t know why. Maybe the desire to please the PO. Or the fact that we never seem to take into account factors such as having a bad day, interruptions, context switch.
T-shirt sizes or even story points are way more effective.
The PO can later translate it to time after the team reaches certain velocity.
I have been developing software for over twenty years, I still suck at giving time estimates.
Time estimations, or conversations to days or other units, typically fail because if a developer says 1 day they might mean 8 focused uninterrupted development hours while someone else hears 1 calendar day so it can be done by tomorrow, regardless of if a developer spends 8 or 16 hours on it.
Yes, I've seen this too in sprint planning. However, the layer of indirection I think is helpful. If you use actual time, then when something isn't done after 1 week when that was the estimate, then bosses are asking why. If your estimate was simply "8 story points", then the bosses can't point to a calendar and complain. They can try to argue that an 8-point task should be done in a week, but then you and the scrummaster remind him that points don't map directly to time, just effort.
