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.