3 ms·

One of the most common mismatches between estimation and execution that I have encountered I phrase, "You never anticipate the unanticipated". During estimation

One of the most common mismatches between estimation and execution that I have encountered I phrase, "You never anticipate the unanticipated". During estimation people are generally optimistic and estimate assuming that they will not encounter any problems or issues along the way. That is rarely the case, and you can never assign an estimate of effort to them in advance since you don't know what those problems will be or how long they will take to resolve. You can assign a "buffer" of effort but this is just plucking numbers out of the air. I know that this is pretty obvious and basic stuff, but I'm amazed at how many people look at me like I'm crazy in planning meetings when I try to temper expectations when presented overly optimistic schedules.

KronisLV 4y ago
> During estimation people are generally optimistic and estimate assuming that they will not encounter any problems or issues along the way. This is especially prevalent when people don't anticipate the overhead of the technical aspects needed to finish some business functionality. And yet, when my estimates are large people look at me odd and try to peer pressure me into not being an outlier. In the end, however, there's certainly a sort of multiplier for working with legacy code or overcomplicated systems.
doctor_eval 4y ago
Yes, a closely related issue is domain knowledge (or lack thereof). Just when you think you’ve finished the job, some non negotiable domain rule comes along and ruins the rest of your month.
kqr 4y ago
> but this is just plucking numbers out of the air. It doesn't have to be. You can learn to give estimations of the "there's a 90 % chance this will be done before date X" and then when you look back at your 50 last projects, roughly 45 of them indeed were done before your estimated 90th percentile point. Granted, the process will still look like plucking numbers out of the air, but the result will be more meaningful for planning than numbers actually plucked out of the air.
teeray 4y ago
There’s also a great deal outside your control for making accurate estimates that is never accounted for: coworkers who don’t review your PRs, flakey build systems, slow build systems, coworkers who do review your PRs but build an enormous punch list of things that may or may not be in scope for the work, complex merge conflict resolution that requires understanding concurrent work, linters that fail your PR, etc.

KronisLV 4y ago

> During estimation people are generally optimistic and estimate assuming that they will not encounter any problems or issues along the way. This is especially prevalent when people don't anticipate the overhead of the technical aspects needed to finish some business functionality. And yet, when my estimates are large people look at me odd and try to peer pressure me into not being an outlier. In the end, however, there's certainly a sort of multiplier for working with legacy code or overcomplicated systems.

doctor_eval 4y ago

Yes, a closely related issue is domain knowledge (or lack thereof). Just when you think you’ve finished the job, some non negotiable domain rule comes along and ruins the rest of your month.

kqr 4y ago

> but this is just plucking numbers out of the air. It doesn't have to be. You can learn to give estimations of the "there's a 90 % chance this will be done before date X" and then when you look back at your 50 last projects, roughly 45 of them indeed were done before your estimated 90th percentile point. Granted, the process will still look like plucking numbers out of the air, but the result will be more meaningful for planning than numbers actually plucked out of the air.

teeray 4y ago

There’s also a great deal outside your control for making accurate estimates that is never accounted for: coworkers who don’t review your PRs, flakey build systems, slow build systems, coworkers who do review your PRs but build an enormous punch list of things that may or may not be in scope for the work, complex merge conflict resolution that requires understanding concurrent work, linters that fail your PR, etc.