<story><title>Tasking developers with creating detailed estimates is a waste of time (2020)</title><url>https://iism.org/article/is-tasking-developers-with-creating-detailed-estimates-a-waste-of-company-money-42</url></story><parent_chain><item><author>harry8</author><text>An estimate is usually the sum of a bunch of smaller estimates. Those estimates have a probability distribution that is asymmetric. While sometimes they can be quicker than anticipated, the lowest they can go is zero (turns out we don&amp;#x27;t need it, cut it) and that kind of thing is relatively less common than a blowout the other way. Those blowouts are uncapped, while zero time is a minimum there&amp;#x27;s no maximum. The unknown unknowns are the things that get you. Seems like it will take X but the frobnicator was broken in ways we couldn&amp;#x27;t have anticipated so we had to get a different thing and then hack it to make it do what we actually needed etc etc. Each individual item has a low probability of that happening to some extent. When you have a bunch of things in sequence one of them probably will if not more.&lt;p&gt;IIRC each item is described by a poisson distribution. (Have I got that right, mean, long tail). Nobody models estimates as a sequence of dependent, poisson distributed events, that I&amp;#x27;ve heard of at least. If you did you might at least get a range on the estimate. Between 2 and 20 days. That would be more accurate. Useful to anyone much? Unclear.</text></item></parent_chain><comment><author>wpietri</author><text>And one of the classic problems with estimates is that common processes tend to bias estimates.&lt;p&gt;For example, what (I think) McConnell calls &amp;quot;picking the first non-impossible date&amp;quot;. An exec asks how long project Magic Pony will take. A manager asks the team and the team comes up with a number. If the number is higher than what the exec imagined, or even higher than what the manager imagines the exec imagines, pressure is applied on the number. &amp;quot;Are you sure? That seems like a lot.&amp;quot; A negotiation ensues, and often the number lands on the first date that engineers can&amp;#x27;t absolutely prove is impossible. Or the first date that engineers won&amp;#x27;t quit their jobs over.&lt;p&gt;For an estimate, we in theory want one where the team has a good chance of hitting it. Say, a 75% chance of success. But iterative pressure from the powerful will shift the distribution to 25%, 5%, 1%.</text></comment>
<story><title>Tasking developers with creating detailed estimates is a waste of time (2020)</title><url>https://iism.org/article/is-tasking-developers-with-creating-detailed-estimates-a-waste-of-company-money-42</url></story><parent_chain><item><author>harry8</author><text>An estimate is usually the sum of a bunch of smaller estimates. Those estimates have a probability distribution that is asymmetric. While sometimes they can be quicker than anticipated, the lowest they can go is zero (turns out we don&amp;#x27;t need it, cut it) and that kind of thing is relatively less common than a blowout the other way. Those blowouts are uncapped, while zero time is a minimum there&amp;#x27;s no maximum. The unknown unknowns are the things that get you. Seems like it will take X but the frobnicator was broken in ways we couldn&amp;#x27;t have anticipated so we had to get a different thing and then hack it to make it do what we actually needed etc etc. Each individual item has a low probability of that happening to some extent. When you have a bunch of things in sequence one of them probably will if not more.&lt;p&gt;IIRC each item is described by a poisson distribution. (Have I got that right, mean, long tail). Nobody models estimates as a sequence of dependent, poisson distributed events, that I&amp;#x27;ve heard of at least. If you did you might at least get a range on the estimate. Between 2 and 20 days. That would be more accurate. Useful to anyone much? Unclear.</text></item></parent_chain><comment><author>virgilp</author><text>I tried to do that! Didn&amp;#x27;t  use Poisson, used normal distribution, but I think that&amp;#x27;s not so relevant - at the end of the day it&amp;#x27;s still just more elaborate guesswork.&lt;p&gt;I think what&amp;#x27;s useful is thinking about the problem, and communicating in group&amp;#x2F; disseminating the information (this is required in order to do the typical &amp;quot;planning poker&amp;quot; or whatever planning technique the team happens to use). Whether you end up with L&amp;#x2F; S &amp;#x2F;M or 7&amp;#x2F;13&amp;#x2F;21 points or whatever else you use - it&amp;#x27;s irrelevant, so no need to sweat it; what is relevant is that you discussed the tasks and everyone has some understanding, and maybe they&amp;#x27;re a little bit better spec-ed now.</text></comment>