skeeter2020 a day ago

This is essentially t-shirt sizing without all the baggage that comes from time. Your boss is trying to use the relative magnitude but it's inevitable that people will (at least internally) do math like "7 day tasks is the same as one week task", or worse over-rotate on the precision you get from day/week/month, or even worse immediately map to the calendar. Suggestion: don't use time.

▲

cnity a day ago | parent [-]

If you pretend not to use time, everyone will do an implicit time mapping in their head anyway. I've never seen it go any other way.

▲

seviu a day ago | parent | next [-]

Surprisingly prob yes

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.

	▲	jrs235 a day ago \| parent [-]
		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.

▲

lmm 17 hours ago | parent | prev | next [-]

It's probably not possible to fully prevent people from thinking about time at all, but the more friction you can add, the better.

▲

SoftTalker 19 hours ago | parent | prev [-]

That's true. Anyplace I've worked where we did planning poker, "points" were always just a proxy for time.