A deprecated part of XpPlanningTerminology, LoadFactor is replaced by ProjectVelocity. By MeasuringProjectVelocity and applying some LoadFactorArithmetic, the LoadFactor converts the estimated IdealProgrammingTime into an estimate of actual time expected to be spent on a UserStory.
Quoted from XpMailingList 2/16/2000:
-
- What I'm doing now is abandoning load factor entirely in favor of committing to the same number of ideal weeks worth of stories in this iteration that we completed in the last iteration.
- Iteration 1: Committed to 8, completed 3
- Iteration 2: Committed to 3, completed 5
- Iteration 3: Committed to 5, completed 6
- Iteration 4: Committed to 6, completed 5
-
- ...
- This gives you a natural breather when you had a rough iteration,
- It removes the temptation to use the load factor as a control variable
- It focuses everyone's mind on completing stories towards the end of iterations
-
- (you don't want to complete 0, ever, because the next iteration planning meeting is going to be mucho unpleasant) and It gets rid of that pesky divide- now I can do the arithmetic again
-
- -- KentBeck
Quoted from the XpMailingList 2/23/2000:
-
- LoadFactor is the inverse of velocity. If I estimate in ideal weeks (which I do before I have comparables), then my load factor is the ratio between those estimates and how long it actually takes me. For me this is between 2 and 5, depending on what else is going on. If my load factor is 3 and I have 3 week iterations, then my velocity is 1.
-
- The confusion comes because we recently started using velocity exclusively, ignoring load factor. For example, I just got back from iteration planning with a client who got 30 days worth of tasks done in iteration 1 (out of 39 committed) then 35 done in iteration 2 (out of 36). They committed to 36 days worth of tasks for iteration 3.
-
- -- KentBeck
Quoted from the XpMailingList 3/24/2000:
-
- LoadFactor is what we used to use as a project metric. ProjectVelocity is recommended now.
-
- Length of iteration (calendar days) times number of people divided by total estimates for the tasks done in the iteration (ideal days). This gives a number usually in the 2 to 4 range. We can do some fancy math for any iteration and determine how many ideal days of tasks we should assign to that iteration. We can even figure out if any developer has signed up for too much work. That is the load factor.
-
- Or we can add up the estimates for all the stories that were completed during the last iteration and use this during the planning game to tell when the next release will be done. We can add up all the estimates for all the tasks that were completed during the last iteration and sign up for that many this iteration during iteration planning. That is the ProjectVelocity. It is a simpler metric.
-
- -- DonWells
Quoted from the XpMailingList 3/25/2000:
-
- What is the difference between velocity and LoadFactor?
-
- Velocity is Effort/Time. It is the true amount of effort you get done per unit time. Usually the denominator is the duration of an iteration. In that case Velocity becomes the amount of work you can get done in an iteration. Some folks use "Day" or "Week" in the denominator.
-
- LoadFactor is Time/Effort. It is the amount of time that passes per unit of effort. This can be useful for estimating duration.
-
- We think velocity is the simpler term, so LoadFactor is falling out of use.
-
- -- Robert C. Martin
Iterations are scheduled in calendar weeks not ideal weeks.
An estimate for a UserStory card should be 1-3 weeks? Calendar weeks or ideal weeks?
Stories need to be mapped to EngineeringTasks. Ideal time estimates are
placed on EngineeringTasks.
In their planning process, DoIt uses IdealTime estimates for each ImpliedRequirement?. This raises another interesting question: how does ImpliedRequirement? relate to UserStory from a granularity perspective? IdealTime is sometimes called UninterruptedDaysToCompletion?. Then we need a factor to turn the IdealTime into CalendarTime?. The factor was originally called a DistractionFactor?, but that had too much negative connotation -- not to mention it is not a very accurate description. The formula basically is:
CalendarTime? = IdealTime / DistractionFactor? -- the only other complexity is converting from IdealTime to CalendarTime?, adjusting for weekends and holidays
Our experience tells us that a DistractionFactor? of about 50%. In other words, we double IdealTime to get RealTime.
We had lately taken to calling this measure ProjectVelocity; but it sounds like this means something different to the posters on this page?
The main reason the statistic is important is because we can estimate better in IdealTime, but we need a way to convert to CalendarTime?.
I guess I missed the point about Ideal Time. How should I calculate IdealTime? In estimating, I usually try to take an actual time from a similar task and use that. Blindly multiplying an estimate by some correction factor just seems to be a highly unreliable way to estimate to me. -- WayneMack
CategoryComparisons
Velocity Vs Load Factor