How to Estimate a Team’s Velocity?
In an Agile Project, at the end of each iteration, the project team estimates effort associated with the tasks completed during that iteration. This total of estimated effort is usually referred to as the velocity.
Only the aggregate velocity of the team is important, not the individual velocity of a single team member; a team is a mechanism intended to yield more than the sum of its parts.
Knowing the velocity, the team will have an estimate of how long a project will take to complete. This is calculated by estimating the remaining tasks against the assumption that the velocity value will remain approximately the same over the remaining iterations.
This serves as a guiding prediction, albeit an imprecise one. Velocity is a measurement; made after the fact at the end of an iteration. It can help and inform future planning but is not itself a budget or forecast. Phrases such as “setting the velocity” reveal a basic misunderstanding of the concept.
If there is an expectation that project conditions will remain the same — for instance, the team will spend the same amount of time doing bug fixing, refactoring, development as they currently are — then using velocity as a measure of progress might provide a good indication. If the conditions change however, potentially the best way to define velocity would be in the team’s ability to turn ideas into definable requirements and tasks.
Another important facet is that comparing velocity across teams is often impractical. Different teams may have different approaches to estimation, have different projects, timescales, and different contextual constraints when deriving their velocity for planning efforts.
To summarise, for velocity to be an effective indicator in measuring team performance, the project factors (team members, activity, product, etc…) should remain the same as much as possible.