Re: [scrumdevelopment] Estimates vs Actuals
- Our automated Scrum tracking built into the GNATS open source bug tracking
system captures initial estimates. Then it takes less than 60 seconds per
developer each day to update time spent on a task and percent complete. Se
complete data is available on every task with minimal effort.
All other calculations are totally automated and information is
automatically dumped every night for import into Excel.
Then the bean counters can count to their hearts content using their
favorite software tool.
Actually, I generate all the reports in my spare time because the system is
so efficient. Occasionally I compare the average time to completion against
initial estimates. In our case, the developers consistently bring in the
tasks at 86% of initial estimate on average. Looking at any one task will
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 DELIVERY.
That is compromised constantly by factors outside the Sprint like customer
emergencies, gratuitous interference by management, other projects or
functionality jammed in by marketing. Ken and I have spent years busting
knees on management teams for gratuitous interference.
If demands are made on delivery dates and the SCRUM is well run, the SCRUM
will self organise to deal with slackers.
I always give other managers all the reporting they want as long as they do
not interfere with the SCRUM process or add any overhead. The one exception
is time sheets which are verboten. Good reporting keeps management out of
CTO PatientKeeper Inc.
At 03:34 PM 10/5/2003, you wrote:
> Date: Sat, 4 Oct 2003 23:48:13 -0700
> From: "Dan Rawsthorne" <DrDan@...>
>Subject: RE: What's wrong with tracking estimates vs. actuals?
>It would be a good idea to track the total estimate versus the total
>actuals, but not at the task level. What makes the totals work out is
>the law of large numbers - that everything averages out. What your boss
>should be hoping for is that your estimates average out to be correct.
>It is unreasonable to expect that every individual estimate will be
>correct, and trying to get that to happen always leads to analysis
>paralysis. However, making sure that your estimates are converging to
>actuals at the iteration level makes sense to me.
>Dan Rawsthorne, PhD, Sr. Consultant
- --- In firstname.lastname@example.org, Jeff Sutherland <jeff.
> Actually, I generate all the reports in my spare time because thesystem is
> so efficient. Occasionally I compare the average time to completionagainst
> initial estimates. In our case, the developers consistently bring inthe
> tasks at 86% of initial estimate on average. Looking at any one taskwill
> just give you a lot of random variation as noted here by others.DELIVERY.
> 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.