Two formulas for calculating Velocity
Assume you have a Team Availability (in hours) before the Sprint, and your team pulls Team Commitment (in hours) work to be done within the Sprint.
TA = Team Availablity
TC = Team Commitment
The Team Availability may or may not include a factor based on earlier Sprints to adjust the amount of work the team can do in a Sprint according to previous Sprint results.
During the Sprint team member might have absence, like sick leave, parental leave, just taking a day off. Lets call this TA’ (TA prim).
During the Sprint some work might be removed and new added, when a team member have unplanned absence you probably want to adjust the TC and remove work that will not be done due to the decreased Team Availability. Or you might add new work since you have been working faster, lets call this TC’ (TC prim).
TA' = The actual Team Availability in the Sprint
TC' = The actual Team Commitment in the Sprint
At the end of the Sprint you have completed some work, that is moved to Done column, this is CW (in hours).
Now, lets calculate velocity, or the Velocity factor, so to say.
VF = CW / TA'
This will give us as Team Commitment for next Sprint as,
TC = VF * TA
This formula is pretty accurate, but can be unfair sometimes. If you keep failing with delivering during the Sprint, it might be several reasons,
- External dependencies are slowing you down
- Internal dependencies are slowing you down
- Build processes are slowing you down
- Administration is slowing you down
- Work takes longer than estimated
Just try to figure out what makes you fail the Sprint, and make a plan on how to resolve or work around the issues. Make an hinders list, and talk about them at each Sprint Review and Retrospective, they are the whole teams concern.
If it is all due to bad estimations, just use the VF to adjust you estimations at first and then continuously improve your estimation technique. If you have a young team you might just need time to learn to do better estimations.
But if you have external dependencies, or internal dependencies, that is hinders that are not that easy to resolve, and that affects your sprint in such way that work has to be replaced with other work in the backlog, you might want to look at how many hours you have been able to “do” in the Sprint. This can be done by using RE (Remaining Estimation).
At the end of the Sprint, you let all developers calculate what is Remaining (in hours) in the work that have not been completed. This is of course an anti-pattern and should be avoided, but it can give you at least a hint of how how many hours actually been put in the Sprint. Now, to do this the developers must be cautious and really re-estimate the remaining time, not just remove hours they have spent on it. The point of remaining is to give a better estimate on how much is left since we will obviously know more of what has to be done the longer we have been working on the issue.
RE = Remaining Estimate
And again, lets calculate a factor to be used on the TC,
HF = (TC' - RE) / TA'
This will give us as Team Commitment for next Sprint as,
TC = HF * TA