Defining Velocity for Your Agile Team
Agile software development, like all disciplines, uses words in its own way. A domain-specific vocabulary can enhance communication, but only when those involved understand the new meaning. One word that is widely used by agile teams but whose definition seems less than ideal is velocity.
When someone on an agile team mentions velocity, they usually are talking about how much functionality a team is likely to deliver in a sprint, often based on historical data about the number of story points a team tends to finish. But there are nuances in how you can interpret the data, such as whether fixing bugs counts in the velocity or we are only talking about new functionality.
For example, the amount of bug-fixing you need is analogous to friction, so if you care about feature velocity, estimates related to fixing bugs might not count. But if you want to measure how quickly you can get work on the backlog done, regardless of type, it should. Or maybe you want to track both numbers to understand the friction in your project.
What teams call velocity might not even measure the amount of work that can be planned for. Many things can change a team’s speed of delivery, including vacations, holidays, or corporate events. Given a term like velocity, you may be tempted to develop calculations like “points per developer day,” but, while useful in a heuristic way, that measurement will lead you to a false sense of precision.
Some teams take the concept of velocity to be more than it actually is, in part due to the catchy, technical-sounding name we use. Velocity sounds scientific and precise, even though agile acknowledges that precision in estimation is difficult, and perhaps not even valuable. The word is even misleading.
As the band They Might Be Giants explains musically and clearly, velocity is a vector indicating speed and direction. There really isn’t a direction associated with the number of story points completed per sprint. What we are measuring is something more scalar, like speed.
Even speed may be misleading, as agile methods are not about speed per se, but value. Having a sense of how fast you deliver can help with short- to midterm forecasting and with making reasonable sprint commitments, but the real test of whether your agile process is working is if you are building increments of the right, deliverable thing at the end of each sprint.
Measuring progress is important, and a lightweight estimation process based on something like story points helps teams not waste a lot of time creating precise estimates that are likely to be wildly inaccurate. But don’t lose track of the goal of an agile approach: delivering the right thing to the customer by inspecting and adapting.
Doing things quickly with quality is good, but don’t let the words you use lead you astray. Rather than measuring velocity, call it speed or even anticipated commitment. And don’t use velocity as a measure of success for your agile process.
