Velocity is one of the more common “measures of success” according to digital.ai’s (formerly VERSIONONE, COLLABNET) Annual State of Agile reports. Velocity’s popularity increased from 38 percent in 2019 to 45 percent in the 2021 survey results. As far back as 2008, velocity was ranked 11th, indicated by 58 percent of respondents, in the same report when asked, “What do you employ with your agile methods?”

As teams employ retrospectives to improve their workflow and activities, they are often pressured to also increase velocity. In this context, velocity is the quantification of the accepted iteration increment, most often represented with story points. Sometimes, the eighth Agile Principle asserting “sustainable pace” is re-imagined as sustainable and faster. The rise in the slope of velocity over time becomes an expectation of maturing self-organized teams, tempting them to minimally give the appearance of higher output. Senior leadership may attempt to compare team velocities in search of “best agile practices” to be adopted by lower velocity teams. While such practices are prevalent, they need to be resisted. The 2020 Government Accounting Office’s Agile Assessment Guide provides another vivid reminder that velocity should not be used across teams.

The question that never seems to go away, “How long do you need to complete the entire backlog?” ignores not only the variation in velocity but also the unceasing changes to the product backlog, as intended with the second Agile Principle. Sadly, velocity can be misused as the sole predictor of story points to be completed in upcoming sprints. Trying to predict an “end date” using story points remaining in the product backlog mischaracterizes the relationship between story points and hours as a derivation rather than what it is, a correlation.

The proclivity to track velocity across teams also has detrimental effects on a team. Insidious consequences await many teams that are pressured to boost velocity:

• The hidden cost of more rapidly accruing technical debt,
• The overall quality of the product,
• The less frequent engagement with the business,
• Shaving time in meetings—especially development team refinement where stories and associated acceptance criteria are more deeply understood and where story points are first established,
• Reliance on velocity as a predictor of sprint delivery performance,
• Reliance on velocity as a predictor of “finishing” the backlog,
• The surrender of cross-functional growth time, and
• Relationship stress among team members who may elevate expectations of each other

Just as teams are often expected to increase velocity, the propensity to disguise any “dips” in velocity heightens across sprints. Yet, variation across sprints is natural, even expected. Fluctuations related to vacation, personal holidays, illness, family crisis, onboarding, and skillset growth need to be acknowledged in learning organizations and “performing” Scrum teams. The ability of the team to explain the causes of variation is more valuable than the ability of a team to portray a constant level of delivery, deceptively represented with manipulated “steady” or inclining velocity. Attempts to track velocity per team member, hours, or FTEs, further exacerbate measurement miscues.

Capacity, that is, the sum of hours of available development team time for the next iteration may serve as a “finer” indicator of potential performance. Much like the antenna-enabled black and white televisions in the 1960s with dual tuners, historic velocity used to project future performance serves better as a “coarse” signal with capacity subsequently serving as the “fine” signal tuner. While velocity may point us towards a predictable range of performance, capacity narrows that cone of uncertainty leading to more reliable sprint commitments and improved credibility with the stakeholders. Enhanced reliability over time can help to alleviate or neutralize some of the teams’ frustration in cultures that persist in measuring agile progress with the traditional cost, schedule, and scope “predictive” parameters.

None of this background is intended to suggest that velocity is useless; on the contrary, self-organized teams can make insightful use of velocity. As examples:

• Velocity might reflect the impact of limited or unavailable team participation across sprints consistent with fluctuations in completed story points. From a statistical standpoint, velocity could help explain special cause variation; the variation that reflects swings beyond normal standard deviation
• The presence or absence of a significant number of team members for personal or business reasons can drive special causation
• The unavailability of a key resource might be another contributor; perhaps an indication that cross-functional skillsets need development
• Velocity swings might also be evidence of less-than-thoughtful estimation on behalf of the development team; certainly another correctable behavior

But note that the consideration of each of these is best addressed by the development team itself—the self-organized team, not someone outside the team. Enabling trust and placing accountability on the team cultivates team maturity and growth. It keeps management, the PMO, and leadership from imposing their will on the team; it fosters growth as a learning organization for building a desirable and sustainable culture.

Velocity can be an asset to the self-organized team and therefore the organization as a whole, or it can become a liability to both when misused. Opt to accrue the assets.