@adhdjesse @codinghorror btw I think I read once that the most accurate way to estimate is to come up with a value, then double it, and then move it up one order of magnitude.
I still do it, and I still miss by a fathom…
I'm currently reading Steve McConnell's new book, Software Estimation: Demystifying the Black Art [http://www.amazon.com/exec/obidos/ASIN/0735605351/codihorr-20]. The section on individual expert judgment provided one simple reason why my estimates are often so horribly wrong:> If you ask a developer to estimate a set of
@adhdjesse Man, I know this is meant to be funny, but my producer brain is now going into all the conversations I've had to have about this in autopilot. It's gonna be doing that all day.
"I get it, just tell me what you think would be unreasonably fast or slow to expect"
"It's fine, we need a place to start, we'll revise this as we go".
"OK, let's break it down into smaller taks and estimate THOSE"
Don't make me turn this thread around and say "bigger than a breadbox". Because I will.
@adhdjesse 72 Blue, 88 red, 61 yellow, 48 purple, 63 pink, 31 orange and 22 green. You owe me $192.50 in quarters. lol
"Still can't believe gumballs are 50 cents each now! Yeesh!"
I try to give estimates in confidence intervals: I'm 50% confident it can be done in x time, 60% in y, etc.
As a bonus, the more granular your intervals, the sooner the person asking loses interest and leaves you alone to actually do the work.