Ats Load Factor

Part of AtsGoesExtreme and the AtsDiary. See also LoadFactor.

In the first phase of the ATS project, I asked for some informal estimates about how much time was spent in implementing new features vs. doing other things (such as fixing bugs or polish). The answers that came back all hovered around 33%, which corresponds to a LoadFactor of three. Unlike a LoadFactor, this figure was based on estimated memory, not solid metrics.

When I started phase two of the ATS project, I needed to determine the project's LoadFactor, but I had no formal numbers to support my initial estimate. So I poked around on Wiki and determined that a load factor of 2 was pretty good, 2.5 was average, and to expect 3 from a new team. So I started with 3, added 0.5 because we were dealing with an existing codebase that only one developer had any experience with, and then subtracted 0.5 since our team of four developers is fairly small. Later on I remembered that our LoadFactor was 3 on the first phase, and also uncovered some significant schedule risks with our developers, so I bumped the number back up to 3.5.

A little later, because of our schedule risks, I had to provide time estimates for teams of four, three, and two developers (see AtsPlanningGame). The 3.5 LoadFactor applied to four developers, and was largely due to the schedule problems of one developer. Removing him, I felt, would bring the LoadFactor back down to 3. Removing a second developer that also had some less significant schedule problems would bring the LoadFactor down to 2.75. Originally, I dropped it down to 2.5, but I bumped it back up a notch because I was reluctant to say that even a two-person team would be more efficient than our original four-person team. That team contained some excellent developers, and there would still be a learning curve for the one of the developers on the two-person team.

That's how I estimated the InitialLoadFactor?... by the seat of my pants and gut feel. (But how else could I do it, since this team has never worked together before?) As the iteration progresses, I'll replace the estimate with an actual, calculated, LoadFactor.

On March 10, 2000, I calculated our actual load factor for the first time. Actually, I calculated two load factors. Our schedule commitment to the stakeholders was based on three developers working 40 hour weeks. But the third developer arrived two days late. So I'm tracking (see AtsTrackingWhiteboard) two load factors -- one, the ActualLoadFactor?, to be used for future planning, and one, the CommitmentLoadFactor?, to be used for tracking our progress vs. our commitments. The ActualLoadFactor? is calculated from the number of hours actually spent in the office by all developers, divided by the number of ideal hours achieved. The CommitmentLoadFactor? is calculated from the number of hours that should have been spent in the office by all developers, divided by the number of ideal hours achieved. The CommitmentLoadFactor? gives us a rough idea of whether or not we'll be able to meet our committed schedule, while the ActualLoadFactor? gives an idea of what we should use in future planning.

As of March 17, 2000, our CommitmentLoadFactor? is 2.6 and our ActualLoadFactor? is 2.4. This number is continually changing; see the AtsDiary for the latest numbers.

Since both of our developers could get pulled away from the project, I'm going to use 40 hours as the minimum number of hours spent on the project each week. That way absences, which presumably will continue at about the same rate throughout the project, will get included in the LoadFactor. The same won't apply for overtime, though: If a developer works overtime, that number is included as part of the number of hours spent in the office. That way, it won't be possible to artificially decrease the load factor by heroic (but brief) bursts of overtime.