zlacker

>>mattjh+(OP)
Is it going to take more than two hours?

Is it going to take more than two days?

Is it going to take more than two weeks?

Is it going to take more than two months?

Is it going to take more than two years?

If you can answer these questions, you can estimate using a confidence interval.

If the estimate is too wide, break it down into smaller chunks, and re-estimate.

If you can't break it down further, decide whether it's worth spending time to gather information needed to narrow the estimate or break it down. If not, scrap the project.

>>xn+VB
There’s also something more concrete about asking “Can you get it done by end of tomorrow? What does that require?”

I prefer it over estimating which feels more like asking the length of a piece of string.

>>scott_+wo1
The problem I have is, conceptually a task always looks easy, but then as your coding, you hit several problems that are not simple to overcome - in fact, lot of times these issues turn into almost insolvable problems that blow out any time estimates ;(

>>alfied+NX1
That’s why time limiting rather than estimating works for me. It forces me to contend with the question: “can I get this done today?” That’s usually an easier question to answer because it’s to tightly time bound. I’m not always correct but I’ll know tomorrow if I wasn’t, rather than next month!

When I’m asked on longer time frames, I’m much less confident but it’s still more concrete than the other way around.