Nigel Fernandes

 

Extending Agile Algebra

Saturday, September 5, 2009

Paulo Caroli at Agile Tips wrote an interesting post on Agile Algebra. The formulas are all very interesting.

However I believe in order to be usable on a project a couple of them need to be extended a little bit. Specifically, the calculation of the expected increase in velocity per pair added.

In each of the problem statements Paulo states the expected increase in the velocity for the new pair in the problem itself. The means to arrive at these expected velocities is not clearly discussed.

If current Velocity of the team is V, and current number of developer pairs is N, then current velocity per pair is V/N

i.e V_p = V/N

Let us assume the values of V_x and N_x hold for an iteration I_x. We'd like to calculate the expected Velocity after adding 1 developer pair.

Adding new people always has a less than linear increase in capacity. Communication overhead (see Fred Brooks), ramp up time etc.

To account for this, a good technique to predict velocity for I_x+1 is as below

If C is the co-efficient of (ramp up time,communication overhead etc..)

∆V can be defined as C * V_p

By Paulo's formula : V_x+1 = V + ∆V

i.e. V_x+1 = V + (C * V_p)

i.e. V_x+1 = V + (C * V/N)

I've seen that a good co-efficient C for I_x+1 is 0.6 for small teams (i.e N <= 6 developer pairs) For larger teams it makes sense to stagger the projected velocity across more than one iteration. V_x+1 = V + (C_x+1 * V/N)

V_x+2 = V + (C_x+2 * V_x+1/N_x+1)

where V_x+2 corresponds to the iteration I_x+2

In such cases values C_x+1 as 0.3 and C_x+2 as 0.6 have given good results but I encourage you to work out suitable values for your team.

A lot of other factors such as length of iteration, technical complexity, skill/experience of pair added, etc will affect how you pick your values for C. That's where the skill and experience of the project manager comes into play.

Its interesting to apply these formulas retrospectively to your project and calculate the values of C. While it may not be accurate (planning rarely is), it does give you a yardstick for the future.

Labels: agile, agile algebra, projects, velocity