<p>Observing one year of estimations during a project I found out some strange things that make me wonder if evidence based scheduling would work right here?</p>

<ul>
<li>individual programmers seem to have favorite numbers (e.g. 2,4,8,16,30 hours) </li>
<li>the big tasks seem to be underestimated by a fix value (about 2) but the standard deviation is low here</li>
<li>the small tasks (1 or 2 hours) are absolutely wide distributed. In average they have the same average underestimation factor of 2, but the standard deviation is high:

<ul>
<li>some 5 minute spelling issues are estimated with 1 hour</li>
<li>other bugfixes are estimated with 1 hour too, but take a day</li>
</ul></li>
</ul>

<p>So, is it really a good idea to let the programmers break down the 30 hours task down to 4 or 2 hours steps during estimations? Won't this raise the standard deviation? (Ok, let them break it down - but perhaps after the estimations?!)</p>

I think it is a good idea. When people break tasks down - they figure out the specifics of the task, You may get small deviations here and there, this way or the other, they may compensate or not...but you get a feeling of what is happening.
If you have a huge task of 30 hours - can take all 100. This is the worst that could happen.
Manage the risk - split down. You already figured out these small deviation - you know what to do with them.
So make sure developers also know what they do and say :)