Velocity is the primary measure of the performance of an Agile team.
The Agile manifesto values “Finished Software” as the primary deliverable of a team, and team velocity is an agile metric that measures that directly.
Measuring Team Velocity:
- The previous article defines Agile success as:
- The team’s ability to plan and complete a set of stories within a sprint, have the work accepted by the business owner, technical reviewer(s) and have zero defects carried over in to the next sprint.
Velocity measures a team’s capacity to do this, by counting Story Points of the stories that are accepted during each sprint. Over time, as a team gets more productive, the team is able to design, code, test and accept more Story Points in a sprint and the Team Velocity rises.
Sound easy to measure? Surprisingly, no! It turns out there are a number of pitfalls waiting to trap the unwary team, giving rise to false or distorted velocity. This shows up as early success, but the team will hit a wall at full speed later in the release! The aftermath of this collision with reality can be pretty ugly, with missed release dates, a stressed-out team and lasting quality problems.
The next 3 posts in this series will address the most common mistakes an agile team can make with agile velocity, and offer suggestions on how to avoid the ugly consequences.