Agile Velocity by Mark Stone

November 2023. A recent conversation led me to realize there are misconceptions about velocity for agile software teams.

First, a digression to set up a metaphor. Why are stock purchases more popular than short selling? After all, if I short a stock at $100 and buy at $90, I make the same money as if I buy at $100 and sell at $110. The asymmetry is this: with short selling, the most I can ever earn is double my money, whereas with a stock purchase my potential gains are open-ended.

Team velocity can be measured in two ways: 1) story points per increment of time (usually a sprint), or 2) cycle time to complete a story. In either case velocity is strictly an internal team measure; it has value if it provides insight to the team. Velocity should never be an external metric by which team productivity is assessed. Furthermore, neither teams nor management above them should expect an increase in velocity.

Writing code faster is not a goal of agile. The goal is to write code better. Better may include faster as a secondary effect, but not a goal. "Better" aligns more closely with higher quality, improved maintainability, and better alignment with customer needs. These are goals of agile.

So if faster is not a goal, why measure velocity? To improve transparency and consistency, thereby improving predictability. Examining velocity prompts conversations about why a team's velocity is what it is, and "why" conversations have value.

I strongly favor cycle time over story points as a measure of velocity. It's a category mistake to equate story points with velocity. Story points establish an ordinal ranking of relative complexity between stories, not a cardinal value of some objective measure. When a team has a shared understanding of the complexity of tasks, that's a strong indicator that they have a shared understanding of the software they steward. Lack of shared understanding points not to a problem with velocity per se, but a problem with communication and knowledge sharing.

With cycle time, I always start by inviting teams to examine the delta between their average cycle time per story and their median cycle time per story. One might think these are essentially the same, but this is where the stock purchase metaphor comes in. There's a limit to how fast a story can be completed -- instantaneously. However, there is no limit to how long a story can remain incomplete. A team with lots of outliers -- stories that are more than a standard deviation faster or slower than the norm -- will see a large delta where average cycle time is significantly greater than median cycle time. This is because of the asymmetry; there's more room for outlier slow stories than outlier fast stories.

And that's the point of velocity measures; to prompt a team to examine why their velocity is what it is. Healthy agile teams will see average cycle time and median cycle time converge, and will see consistent, predictable cycle time from one sprint to the next.

Add / view comments.