1973Re: [scrumdevelopment] Estimates vs Actuals
- Oct 5, 2003Our 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
- Next post in topic >>