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

[extremeprogramming] Re: Load Factors

Expand Messages
  • Ronald E Jeffries
    We really are dropping load factor from the process. Estimate stories in pure programmer weeks, then measure how many pure programmer weeks worth of work the
    Message 1 of 9 , Jan 12, 2000
      We really are dropping load factor from the process. Estimate stories in
      pure programmer weeks, then measure how many pure programmer weeks' worth
      of work the team gets done per iteration. Use that number "Project
      Velocity" to see how long it will take to do how much.

      Do the same thing with tasks in Iteration Planning, except estimate in pure
      days. See how many days work the team gets done in th iteration. Use that
      number to decide when iterations are full.

      At first blush, this is weird. All it's doing, however, is taking the raw
      measured number and not scaling it back up and back down by load factor.
      It's simpler and will work just fine. Think about it ... so you'll be ready
      when we finally get it written up that way!

      Regards,
    • Martin Fowler
      ... That is exactly what it is. People have suggested different load factors for different people on a single team, but as far as I m aware nobody s needed to
      Message 2 of 9 , Jan 13, 2000
        > This sounds like a load factor is used to scale estimation faults.
        > Each estimation is scaled so the true effort can be derived. You can
        > even have different scale factors depending on the developer who
        > estimated...

        That is exactly what it is. People have suggested different load factors for
        different people on a single team, but as far as I'm aware nobody's needed
        to do that yet.


        >
        > I hope there's more to it. Minimizing a load factor would be a goal,
        > and if it is really a "load" factor it relates to disturbances,
        > meetings etc. But then, a load factor (or an average load factor)
        > could be a measure for the corporate culture of the company.
        >

        I'm afraid that is all there is to it. Measuring relative effectiveness of
        teams (or companies) is beyond what I know how to do.

        However if you get a change in load factor for a team, then it's worth
        thinking about why that is, and if it is a symptom of a problem.

        Martin
      • Kent Beck
        Load factor is a recognition that it is easier to estimate if you don t try to solve two problems at once: * How big is this piece of functionality? * What is
        Message 3 of 9 , Jan 14, 2000
          Load factor is a recognition that it is easier to estimate if you don't try
          to solve two problems at once:
          * How big is this piece of functionality?
          * What is the productivity effect of the social context in which I
          program?

          If I try to say, "How big is this compared to other things I've done, and
          I'm going on vacation next week, and there's that stupid meeting on
          Thursday?" I don't do a good job of answering the original question. If
          instead I simply say, "How big is this compared to other things I've done?"
          I do an adequate job of answering. The effects of all the other stuff turns
          out to be fairly static, so I can simply measure my progress and expect to
          do about the same again.

          I'm sure some Captain Horn Hair will try to make the velocity into a control
          variable, "Well, how fast could you get done if the team got 12 weeks worth
          of stories done every iteration?" "We don't, we measure consistently that we
          get 8 weeks worth done." I hope that all the data extreme teams gather will
          help give them the courage in this situation not to overcommit, no matter
          how much pressure they receive.

          As someone said earlier, you get points in XP for having precise estimates,
          not small estimates. If I can nearly predict the future it's easy to manage
          a project. If I go real fast, but I'm not sure how fast, I have a much
          harder time managing because I have to make more, bigger corrections.

          Kent
        • tottinge@concentric.net
          ... I asked this question a lot when I was traveling, because I wanted to see what numbers people used when given estimates. I talked to people about current
          Message 4 of 9 , Jan 17, 2000
            On 12 Jan 00, at 17:41, Marquardt,Klaus wrote:

            > Martin wrote:
            >
            > > Load factor hasn't really got anything to do with the pairing. It is a
            > fudge
            > > factor between time spent productively and calendar time. It is only a
            > > device to help estimating, so the number is meaningless outside the
            > context
            > > of the project that's using it. You certainly cannot compare teams by
            > > comparing load factors.
            >
            > This sounds like a load factor is used to scale estimation faults.
            > Each estimation is scaled so the true effort can be derived. You can even
            > have different scale factors depending on the developer who estimated...
            >
            > I hope there's more to it. Minimizing a load factor would be a goal, and if
            > it is really a "load" factor it relates to disturbances, meetings etc.
            > But then, a load factor (or an average load factor) could be a measure for
            > the corporate culture of the company.
            >
            > How do you use your load factor? Per developer, to adjust her estimates - or
            > per team, and as a basis to optimize the project's environment?

            I asked this question a lot when I was traveling, because I wanted
            to see what numbers people used when given estimates. I talked to
            people about current organizations and previous ones.

            In companies not doing pair programming (remember that a lot of
            the numbers were from years ago), I've always heard factors of 2.5
            to 3, and some even higher. They called them 'fudge factors' and
            referred to nothing but the actual v. estimated ratio, gathered
            statistically over several projects. It's not unusual to see numbers
            like that.

            Some of that time goes to wait time (compiles, system downtime,
            etc). Some of it goes to meetings. Some of it is documentation
            time and document review time. Some of it goes to bugs that are
            harder to fix than anyone thought. Some is miscellaneous (time
            tracking, bio-maintenance breaks, phone calls).

            It's apparently "normal" for jobs to take 2-3 times longer than you'd
            expect.

            I'm not saying that it's ideal, or good, or bad, only that it's true.

            Admittedly, my sampling was unscientific, and probably only
            included maybe 100 organizations tops. But I only wanted to get
            an understanding, not prove a point.

            Tim
          • Eric Ulevik
            Message 5 of 9 , Jan 27, 2000
               
            Your message has been successfully submitted and would be delivered to recipients shortly.