Velocity as productivity

We continue to see teams and organizations equating velocity with productivity. When properly used, velocity allows the incorporation of \”yesterday's weather\” into a team’s internal iteration planning process. The key here is that velocity is an internal measure for a team, it is just a capacity estimate for that given team at that given time. Organizations and managers who equate internal velocity with external productivity start to set targets for velocity, forgetting that what actually matters is working software in production. Treating velocity as productivity leads to unproductive team behaviors that optimize this metric at the expense of actual working software.

Of all the approaches that we might disagree with, equating velocity with productivity has become so prevalent that we felt it important to call it out in our hold ring. When properly used, velocity allows the incorporation of "yesterday's weather" into the iteration planning process. Velocity is simply a capacity estimate for a given team at a given time. It can improve as a team gels or by fixing problems like technical debt or a flaky build server. However, like all metrics, it can be misused. For example, over-zealous project managers attempt to insist on continual improvement of velocity. Treating velocity as productivity leads to unproductive team behaviors that optimize the metric at the expense of actual working software.