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
What if the project involves trying one approach for a week, then assessing whether that approach still looks viable vs moving onto a different approach? This happens a lot with challenging projects, you basically just keep trying different things until one works.

>>n4r9+uv1
Then you know that it's going to take at least, say two weeks, one week for the first implementation and a week to finish it if it works.

On the high end, could it take more than 2 years? 1 year? 6 months? Stop when you are 80% confident that it won't take longer than some period.

So your estimate might be between two weeks and six months. Is that an acceptable estimate for the "buyer"? If not, is it worth expending effort to narrow the estimate?

>>xn+vc3
Yes, this is basically what happens. Except sometimes there's no realistic way to narrow the estimate. In research-focused teams you don't "scrap" a project that you can't break down. Instead you need to have a way to manage wide estimate windows.