Loading ...
Sorry, an error occurred while loading the content.

Re: [scrumdevelopment] Estimates vs Actuals

Expand Messages
  • Jeff Sutherland
    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
    Message 1 of 2 , Oct 5, 2003
    • 0 Attachment
      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
      the Scrum.

      Jeff Sutherland
      CTO PatientKeeper Inc.


      At 03:34 PM 10/5/2003, you wrote:
      >Message: 2
      > 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 ;-)
      >
      >Dan Rawsthorne, PhD, Sr. Consultant
      >www.netobjectives.com
      >DrDan@...
      >office: 425-269-8628
    • Øystein Mehus
      ... system is ... against ... the ... will ... DELIVERY. We use a different bugtracking system, but also track this data in the program, and like Jeff said it
      Message 2 of 2 , Oct 6, 2003
      • 0 Attachment
        --- In scrumdevelopment@yahoogroups.com, Jeff Sutherland <jeff.
        sutherland@c...> wrote:
        > 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.

        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.

        oystein
      Your message has been successfully submitted and would be delivered to recipients shortly.