Uncertainty buffers

It also became a bit of a standing joke that these estimates were not only painstakingly worked on over days or weeks, but as soon as we gave them to a project manager, they would double the figures. When we challenged that practice, they'd remind us that all software developers are optimistic and that buffers were needed.

But it's not that we're optimistic by nature; in fact, a lot of us had already factored in our own buffer allowances. The explanation is more straightforward; the work we do is novel—more often than not we are working on something entirely different from what we've built before: different domain, different technology stack, different frameworks, and so on. 

Some teams would combat this by offering two figures as part of their estimates. The first being the time estimate, the second being the level of certainty that they could complete it within that timeframe. If the task was straightforward, then they would offer their estimate with 100% certainty. If the task was more complicated they would lower the percentage accordingly. The higher the uncertainty, the lower the percentage.

This certainty factor could then be used to allocate a buffer. As certainty got higher, the buffer would get smaller, but even with 100% certainty, there would still be a buffer. After all, there is no such thing as an ideal day as much as we would like to think there is.

At the opposite end of the spectrum, the more the uncertainty in the estimate, the larger the buffer. At the extreme, it was not uncommon to have buffers of 200%.