According to the Agile alliance glossary the definition of Velocity is
// At the end of each iteration, the team adds up effort estimates associated with user stories that were completed during that iteration. This total is called velocity. //
This means that velocity is a way to capture historical capacity of delivering user stories when the sprint/iteration is completed.
There are many unknowns here like:
– how big is a user story
– what was the actual skill level in the team for the specific type of stories delivered
– what activities were actually involved in Definition of done
– was the stories well defined
– was the initial effort estimation correct or not
– where there practical things like vacations affecting the teams capacity
– …
Over time the team will be better at estimating effort needed to accomplish something, but because of the unknowns and the lack of possibility to look into the future estimations will be wrong.
A common approach for traditional management is to use velocity as a way to plan capacity of a team going forward, and make commercial comittments based on the assumption that the velocity is a constant. This, to me, is wrong since it comes too close to traditional project planning and resource allocation. All velocity should be used as, is input to the planning process (PO/team) defining the items on the backlogs.
