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 items 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?
- Capacity - 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.66 Hours , 1/2 = 4 Hours, 1/1 = 8 Hours
- Velocity - 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 18.62 development hours are available per day. Multiply the number by the number of work days in the sprint to arrive at the total of initial work hours. These work hours will be applied against your estimated items, to arrive at an initial velocity.
(7 [Developers] * 1/3 [Load Capacity Factor]) * 21 [Work Days] = 44.1 [Ideal Work Days]
Ideally, the team should already be formed and stable, so that you can just forecast. Unfortunately, this whole scenario is faulted. Not only are estimates for team capacity going to vary wildly, but what about the estimates for the deliverables themselves? I can get pretty good at estimating a level of effort for work that could take a few days. But the contractor that was noted in this post was estimating a 3-year project. By the way, if you're curious, the contractor failed within 1 year. The federal agency then exercised their right to not renew their contract for the option years. The agency then brought in a new contractor with more Agile experience.