In organizations in which agile transitions take place, the ancient English proverb Blood is thicker than water is frequently appropriate. It is decided to adopt agile working, there is talk of Scrum, self-organizing teams, Sprints, standing meetings, sticky notes on the wall, etc. etc. Everybody has to change with the times, the whole organization has to change. But when push comes to shove people easily return to old habits, by re-instating the Command and Control method, with a dent in the belief in self-organization as a result.
Management often looks for methods to gain more insight into the costs and benefits of agile working, with the purpose of control and managing. For that kind of data a lot of agile tools are a blessing, because they include all kinds of report functionalities. At a push of a button all kinds of information, reports and graphs can be accessed that relate to the performance of agile teams, provided the teams have updated the tool correctly with data.
Just consider the reports on the velocity of teams. Frequently these reports are used to compare the performances of teams with each other. Or to see how the velocity develops over time, “because as a team gets better, its velocity will increase”, people often wrongly think. Furthermore, velocity turns out to be related to costs; in other words, what does a team cost per story point?
This worries me. First of all, one cannot compare teams with each other based on velocity numbers. An average velocity of 20 for team A and 25 for team B implies nothing more than that team A has a velocity of 20 story points and team B a velocity of 25 story points. That’s all. Each team attaches its own value to the story points; 5 story points with team A is not synonymous with 5 story points with team B.
When velocity rises over time, then it might mean that the team is improving, but that is not necessarily the case. It may also imply that the team has estimated Product Backlog Items higher than before. A team can improve without this being visible through velocity. For example, when the team needs less and less time to accomplish results, and consequently expands its Definition of Done. Within the same time, a team can accomplish a lot more output within the same time, which will improve the quality of that output, while the velocity remains similar.
Evidently when a team never implements any improvements and never develops, the velocity might not chance. Then the Scrum Master has a challenge.
The velocity is exclusively owned by the development team. It merely provides the team itself and the Product Owner with an indication of how much work can be down within one Sprint. And the Product Owner can use it to determine how much work may be ahead before a certain Product Backlog Item is addressed (provided the current situation does not change).
My advice: Leave the velocity at the Development Team. You already know what the costs are; you know the composition of the team, you know how long the Sprint takes, so you can calculate the costs per Sprint per team. If you wish to compare, compare on the basis of value, on outcome, not on output.
Special thanks to Ron Brouwer (www.c1rcularmovement.com) for helping me with the English translation.