--- In firstname.lastname@example.org
, Jeff Sutherland <jeff.
> Actually, I generate all the reports in my spare time because the
> so efficient. Occasionally I compare the average time to completion
> initial estimates. In our case, the developers consistently bring in
> tasks at 86% of initial estimate on average. Looking at any one task
> just give you a lot of random variation as noted here by others.
> The real challenge is not time to complete tasks. It is TIME TO
We use a different bugtracking system, but also track this data in the
program, and like Jeff said it only takes a few seconds to update the
data, and a few minutes to generate the reports which can be collected
any time, every day.
I've found the numbers useful as a tool in release planning. They
allow me to automatically generate a buffer "protecting" the release
based on the SSQ technique described in Mike Cohn's book in progress,
"User Stories Applied for Agile Software Development" on userstories.
com. I treat estimates as 50% estimates and auto-generate the 90%
"estimate" based on the historical deviation from estimates and
actuals (currently about 70% of tasks come in on or before time).
We don't steer by the buffer, but I find it adds some value to monitor
the buffer development from time to time.