Traditionally the velocity (V) of agile teams is calculated as number of story points (SP) delivered per sprint. If our team is static, that means, it consists of the same or at least the same amount of people in each sprint we can get a velocity that really reflects the team performance.
Although highly desireable, from my experience static teams are not very common. In fact most teams have a certain degree of dynamics, especially in long running projects.
Typical reasons are
- Vacation or sick leave
- Daily business (especially team members from the business are not 100% commited to the project, as they still have their daily duties)
- Partial engagement (specialists are only part of the team when their knowledge is required)
How can we calculate the velocity for those dynamic teams? By taking capacity into account and combining it with the team velocity. I can recommend following procedure that I used on several projects with very good results.
- Have a sprint planning meeting with all people that might have something to deliver in the next sprint or delivered something in the previous sprint.
- Ask every person how much days she plans to commit to the next sprint. This is the planned capacity (PC). Adjust PC if necessary during the sprint planning session based on the selected user stories. Use PC as a basis to plan the next sprint.
- Ask every person how much days she really committed to the previous sprint. This is the delivered capacity (DC). The delivered capacity might differ from the planned capacity announced in the previous sprint planning metting. That is normal for the reasons given above.
- Calculate the capacity based velocity like this CBV = SP/DC.
The advantages of capacity based velocity are:
- It is based on empiric data (delivered capacity instead of planned capacity). It reflects what really happened and not what was supposed to happen.
- It grounds story points (virtual) with capacity (real) as it takes capacity into account in addition to the story points. But beware! Once the SP/DC ratio (how many days do we need to implement a story point?) is known after some sprints, it is tempting to perform planning with capacity instead of story points. This is a bad idea as it brings us back to the notion of exact planning which we (hopefully) learned is not possible.
- It allows the projection of realistic project release dates as we have a stable measure even if the team structure varies.