← Back to context

Comment by resource_waste

8 hours ago

A thank you to HN who told me to multiply my estimates by Pi.

To be serious with the recipient, I actually multiply by 3.

What I can't understand is why my intuitive guess is always wrong. Even when I break down the parts, GUI is 3 hours, Algorithem is 20 hours, getting some important value is 5 hours... why does it end up taking 75 hours?

Sometimes I finish within ~1.5x my original intuitive time, but that is rare.

I even had a large project which I threw around the 3x number, not entirely being serious that it would take that long... and it did.

Because "GUI" and "Algorithm" are too big. You have to further decompose into small tasks which you can actually estimate. An estimable composition for a GUI task might be something like:

* Research scrollbar implementation options. (note, time box to x hours).

* Determine number of lines in document.

* Add scrollbar to primary pane. * Determine number of lines presentable based on current window size.

* Determine number of lines in document currently visible.

* Hide scrollbar when number of displayed lines < document size.

* Verify behavior when we reach reach the end of the document.

* Verify behavior when we scroll to the top.

When you decompose a task it's also important to figure out which steps you don't understand well enough to estimate. The unpredictability of these steps are what blows your estimation, and the more of these are in your estimate, the less reliable your estimate will be.

If it's really important to produce an accurate estimate, then you have to figure out the details of these unknowns before you begin the project.