While reviewing proposal documentation yesterday, I noticed the contractor’s predicted velocity rate was pretty high. Being they are not experienced in using Agile and they haven’t even started the project, I was curious how they were able to calculate such a high velocity rate for the first iteration. I know how many developers they intend to use and I know their proposed iteration durations. I’m not going to get into the specifics as to how they estimated features (user stories, requirements, backlog items, etc.). So, what did I expect?
Velocity is a very simple method for accurately measuring the rate at which teams deliver business value. To calculate velocity, simply add up the estimates of the features successfully delivered in the last sprint or iteration. What about the initial iteration?
Terms to understand when calculating initial velocity:
 Number of Developers
– How many developers will you have doing actual work?
– What is the maximum amount of work one person can accomplish in an ideal situation during the iteration?
 Number of Iteration Days
– How many work
days are in the iteration?
 Load (Capacity) Factor –
The ratio of the actual work output over a period of time and the output if the developer had operated at full capacity over that time period. e.g. 1/3 = 2.4 Hours , 1/2 = 4 Hours, 1/1 = 8 Hours
– How much Product Backlog value a team can deliver in one iteration.
Because you don’t know team velocity for the first iteration, plan initial velocity at one-third of total capacity in order to account for coffee breaks, design, email, meetings, rework, research, etc. As an example, with seven (7) developers and at one-third (1/3) capacity, a total of 2.1 ideal developers are available. Multiply the number of ideal developers by the number of work days to arrive at the total of ideal work days. These ideal work days will be applied against your estimated features, to arrive at an initial velocity.
(7 [Developers] * 1/3 [Load Capacity Factor]) * 21 [Work Days] = 44.1 [Ideal Work Days]