Velocity is the number of story-points completed during an iteration. It is the most common and natural metric for teams using iterations. Time-over-time, the team can measure its increase (or decrease) in its effectiveness in delivering releasable implementations of requirements. It is powerful and effective within a team.
It is not, however, effective between teams.
Velocity depends on story-points and story-points are relative estimates to other stories that a particular team is working on. They are not relative to what other teams are working on. One team may use an approach that assigns 5 points and 3 points to two stories that a proportional effort of about 150%. Another team may assign 3 points and 2 points. The first team will show a higher velocity, even though the work effort is the same. If the two teams are being compared based on velocity, then the second team could easily push up its velocity merely by 8 and 5 to the two stories. Same work but arbitrarily different velocities.
Some organizations try to standardize story-points. This seems reasonable, but it does not work. For example, they might provide standard stories that are given story-point values. One problem is, these standard stories do not take into account the wide variation in the actual stories that are worked on by the teams, the communication and relationships between the requirement detail providers and the implementers, and the details that emerge when the stories are implemented.
The other problem is that teams are not homogeneous. They have different numbers of people with different skill sets and experience in the project domain and the technology. They may also have different responsibilities for work outside of the main project which they are implementing.
Velocity is for a team, not for inter-teams.
Comments
Inter-team velocity is the position, what are the interests?
Mon, 2011-10-10 17:30 — jchyipWhat are the underlying problems that lead to people wanting to have inter-team velocity?
What I've Seen
Fri, 2011-10-21 18:53 — Chris GilhamManagers want predicability on projects with minimal up-front investment; as I call it, Agile-level pre-work with Waterfall-level estimation accuracy. They want to be able to predict how long two apples and oranges tasks are going to take by just simply doing a pointing excersize. It never works out as expected, and if it does, it's a happy accident.
The worst thing I've seen is our attempts at "Department-Level Kanbans". The velocity these establish is basically a meaningless number. Because a single deparment has multiple software projects (so you lose the concept of relative sizing) as well as ticket-response duties.