[IshKebab]

I don't think t-shirt sizes is absurd. It's one of the few good ways that really conveys "we have only a very vague idea how long this will take".

Story points are dumb because they always are just a bad proxy for time.

Really though, the right solution is time plus confidence. Instead of "4 days" it should be "1-8 days" or whatever.

Unfortunately a large number of people simply can't comprehend this, and also no tools support it, so I've never seen it actually done. I imagine management wouldn't like it either because then they can't pretend they have a perfect plan with no uncertainty.

[Kon-Peki]

> Really though, the right solution is time plus confidence. Instead of "4 days" it should be "1-8 days" or whatever.

It's a half-assed reimplementation of PERT charts, which were invented in the 1950s and used successfully for many decades, until everyone decided that everything old is terrible.

[conductr]

I feel like if that task took 8 days you’d end up having to explain everything that happened and why it couldn’t be done in 1.

[IshKebab]

What would you rather - it took 8 days and you said it would take 1-8 days, or it took 8 days and you said it would take exactly 4 days?

In any case, there should be absolutely no problem explaining why it took 8 days if it really did.

[ruszki]

I never understood this sentiment. It seems to me that the communication is broken, when a developer has problems with delays. It’s not their decision, and it’s not their risk. If developers report uncertainties properly, even during development, when a previously unknown unknown appears, or a known unknown takes longer than it was estimated, it’s not their fault. If this doesn’t happen, it’s obviously difficult to explain. Otherwise, I never had problems with even delays 4x the original estimation, because every party knew even from the start, that we had no idea how the end result would look like.

[conductr]

> if it really did

The fact you even had to say that part points to the management problem at hand. Not only are you trying to keep idle time low, you're trying to estimate essentially unknown timelines, and you have to think about whether people are even telling the truth or padding hours where they feel they can.

I just think the range is too wide. Sure anything can be a 1 day task (potentially just an easy solution to add in, or some variables/settings to change, etc). And any 1 day task could be turned into an 8 day task (anything from refactoring unnecessarily, all the way to just walking the dog too frequently). I'm left wondering, how long should this task have taken?

[IshKebab]

I don't really follow you to be honest.

> Not only are you trying to keep idle time low

Yes... I'm paid to work.

> you're trying to estimate essentially unknown timeline

Yes. The exact amount of time the task will take is unknown. That doesn't mean I have no idea how long it will take. The point of the estimate is to tell other people my idea of how long it will take. Even if I only have a rough idea it is probably a better idea than a lot of people.

Incidentally I've found that a lot of people don't understand that, and I have a hack! If you find yourself in a situation where you're waiting for something... let's say roadworks, and you say "any idea how long it will take?" and they refuse to give an estimate, even though they clearly have a better idea than you... What you can do is suggest an outlandish number, and then they'll say "oh no no not that long. More like x".

Worked every time I've tried it.

I can't parse your second paragraph at all.