Hi all,
I know it's been covered a number of times before, but I just wanted to report on a real-life experience of Critical Chain estimating.  On this particular project, just over a month ago, I decided to try an experiment. Our process involves taking user stories and breaking them down into small development tasks which, being small, should be relatively easy to estimate. But iteration after iteration we were squeezed at the finish post because some tasks had taken way too long. I had no idea what the cause might be, but in my mind I coupled it with the team's overall apparent lack of urgency. Things just drifted along.

So just before the next iteration's planning meeting we had a team workshop. I explained the critical chain view of estimates, and we decided to give it a go. The team recognised that historically all of its task estimates had been conservative. Fear of being late had made us create estimates that were universally over at the 90-100% end of the range of possibilities for each task. That is, each estimate created a 90-100% chance of "being right", of finishing within the estimated time. So we had stacked each iteration with 15-20 small tasks, each of which had only a small chance of being late. And each time, one or two were indeed late. No-one knew why, and yet those few late tasks ate up the iteration's slack. Every time.

So we removed the pressure on any individual task to be brought in "on time", and we switched to estimating every task at the 50% point. That is, we did our usual conservative estimates and then halved them! The results were amazing, and have been repeated now over three iterations:

Most tasks are now finished by the 50% point (partly because the developers treat the estimate as a timebox - "I'll do what I can in that amount of time, and then see where we are.") And those that go over just eat into the project buffer a little. In fact, we're now getting a whole load more tasks done in the same time. Critical chain estimating has eliminated the effect of Parkinson's Law and simultaneously created a sense of urgency.

I'd love to know whether this works or has worked for other software teams.