Agile Velocilty
The measurement of the time taken for the team to complete an iteration.
Velocity is used in combination with what are know as "Work Units" to give more accurate task time estimations.
This is a useful record as it allows one to measure the difference between the estimated time and the actual time it takes the team to actually do the work.
Using this value, you can adjust the estimates for future iterations and maybe projects as a whole.
E.g.
4 developers on your team including yourself.
5 iterations in a project release. Each iteration is 2 weeks (10 days ).
iteration 0:
You and your team estimate 5 features can be implemented.
At the end of the iteration only 4 of the features are completed, it takes another 3 days to complete the final feature.
The iteration has actually taken 13days in total therefore the Velocity is currently 13/10 = 1.3. Use this 1.3 as a multipation factor in the estimation for the next release.
iteration 1:
You and your team estimate 4 features can be implemented.
You imply your Velocity value from the previous iteration, 1.3.
To make the calculation easier you break the iteration into Developer-days i.e. 10days x 4 developers = 40developer days.
You imply your Velocity value, 40 x 1.3 = 52 developer-days. There's only 40 developer-days in a release so something must change, something must be cut.
You re-calculate, 4 features will take 52 d-days therefore 3 features will take 3/4s of that i.e. 39 d-days, perfect, so you cut one of the features. You now estimate there will be 3 features for this iteration.
Again at the end of this iteration you see that the 3 features only took 30 d-days, that's 30/40 so you can re-adjust the Velocity but this time in the opposite direction, 0.75.
Use this Velocity value of 0.75 as a factor when finding the real estimation for the next iteration.
etc etc
Velocity is used in combination with what are know as "Work Units" to give more accurate task time estimations.
This is a useful record as it allows one to measure the difference between the estimated time and the actual time it takes the team to actually do the work.
Using this value, you can adjust the estimates for future iterations and maybe projects as a whole.
E.g.
4 developers on your team including yourself.
5 iterations in a project release. Each iteration is 2 weeks (10 days ).
iteration 0:
You and your team estimate 5 features can be implemented.
At the end of the iteration only 4 of the features are completed, it takes another 3 days to complete the final feature.
The iteration has actually taken 13days in total therefore the Velocity is currently 13/10 = 1.3. Use this 1.3 as a multipation factor in the estimation for the next release.
iteration 1:
You and your team estimate 4 features can be implemented.
You imply your Velocity value from the previous iteration, 1.3.
To make the calculation easier you break the iteration into Developer-days i.e. 10days x 4 developers = 40developer days.
You imply your Velocity value, 40 x 1.3 = 52 developer-days. There's only 40 developer-days in a release so something must change, something must be cut.
You re-calculate, 4 features will take 52 d-days therefore 3 features will take 3/4s of that i.e. 39 d-days, perfect, so you cut one of the features. You now estimate there will be 3 features for this iteration.
Again at the end of this iteration you see that the 3 features only took 30 d-days, that's 30/40 so you can re-adjust the Velocity but this time in the opposite direction, 0.75.
Use this Velocity value of 0.75 as a factor when finding the real estimation for the next iteration.
etc etc
Comments