What is Velocity?

Velocity is a Vector

A vector is an entity that has both magnitude (size) and direction.

Velocity indicates the speed of something in a particular direction.

In physics, velocity is the rate at which an object changes its position. An object that oscillates at a high speed, but always returns to its starting position has a zero velocity.

Velocity is the rate at which a team delivers value to the customer. A team that completes lots of tasks, but delivers no value to the customer should have a zero velocity.

In agile software development, velocity is the rate at which a team delivers value to the customer. Value is quantifiable, and we can therefore say it has size. The direction is indicated by the traversal from idea to implementation. A team that completes lots of tasks, but delivers no value to the customer should have a zero velocity.

I say “should” because I see an awful lot of teams that measure velocity based on criteria other than value to the customer. Some consider a story done when development is complete. Others are a tad more “mature” and count a story as done when it is ready to go to production. Not actually in production, mind you; that takes weeks — what with manual testing requirements and change control procedures and getting into queue for the operations team… And some teams consider a story complete once it is actually in production. But even that assumes value to the customer. What if you didn’t count a story as done until customers were actually using it and liked it? If velocity is the rate at which we deliver value to the customer, wouldn’t a true measure of velocity include verification of value delivery?

But I digress a bit, perhaps.

For the sake of this book, let’s go with “in production” means done. In this book, we won’t get into details of how to deliver at the end of each iteration, much less continuous delivery.

Velocity is a Lagging Indicator

Velocity is also a lagging indicator. It is a measure taken at the end of a series of steps. We plan, we prioritize, we work, we test, and then we measure.

Lagging Indicators are Abstract

Lagging indicators tend to be aggregate or abstract. They don’t provide detailed insight into the operations, rather they provide an indication of results. Net profit is a lagging indicator for a company. While it tells us about how the company is doing, it gives us no indication of why the organization was or was not successful.

Let’s look at another lagging indicator; unemployment. The unemployment index is a lagging indicator. It tells us whether or not unemployment is on the rise or decline, which in turns tells us if the economy is doing poorly or well, respectively. An increase in unemployment means a sagging economy. A decrease in unemployment means a growing economy. But there is nothing about unemployment that tells us why the economy is performing in a particular manner or how we might go about making an adjustment to economic policy to bolster growth. Moreover, the way to bolster the economy is not to focus on unemployment, but to address the underlying issues.

Historically, policies focused on training and jobs creation have had little or even negative impact on employment among the populations the programs target ³. Those that did create new jobs, such as the Works Progress Administration of the 1930s and the Public Employment Program of the 1970s and 1980s, did little to impact generation of jobs outside of those directly created and funded by the programs. Essentially, these created an artificial drop in unemployment, but did not address underlying causes. Each program resulted in a corresponding increase in unemployment once government funding ran out.

Whereas, policies focused on addressing broader monetary and fiscal trends can result in a boost in Aggregate Demand, which then leads to a decrease in unemployment.

Similarly, one of the problems with velocity as a lagging indicator is that while it can tell how much work we delivered over a given time period, it cannot tell how well the team is doing at ensuring consistent delivery or at improving their process overall. For some teams, velocity may be an indicator of team health or at least capability, but it provides no insight into root causes. Moreover, attempts to increase velocity directly tend to either create artificial increases that are not sustainable or result in other more detrimental issues. Whereas, efforts to address underlying causes more often than not result in improvements in velocity. Managing story composition and limiting work in process results in smoother flow, which leads to a more stable velocity and the ability for a team to mature into more rapid delivery.

A stable or slightly increasing velocity is usually considered a good thing. When managers see a stable velocity from iteration to iteration, they may become complacent and forgo any improvement efforts. But the reality is that there are actually numerous factors that impact a team’s ability to deliver and the current velocity trend may be more a matter of coincidence than performance. We will look at a number of factors that impact velocity in later sections.

Lagging Indicators are Poor Short-term Predictors

Lagging indicators⁴ tend to be weak indicators for the short-term and are much more reliable for confirming long-term trends.

Let’s take a look at “velocity” in a different industry.

For retail, we can use sales volume as our “velocity”. Sales volume is a lagging indicator which tells us something about how we did in the prior period, but does not give us any indication as to why sales was high or low.

The following shows 10 years of retail sales for a narrow set of products.

Retail Sales Volume by Period

From this graph, we can discern some patterns. We know Q4 sales are consistently higher than the others. And we know that Q1 sales are normally the lowest at approximately 75% of the prior Q4. We can also see that the sales from the prior quarter is often not a good indicator of what the next quarter’s sales will be. Sure, we can look at the long history and determine average percentages and apply that to get a fairly good guess. But we need the long history. Looking at only the prior quarter’s sales is insufficient for determining the next quarter’s sales.

Similarly, our velocity from the immediately concluded iteration is not often a good indicator of what the velocity will be in the next iteration. From one iteration to the next, velocity can vary wildly due to any number of factors.

But, like retail sales, we can look at velocity over time and confirm trends we might suspect, such as a lower average velocity during holiday seasons. This doesn’t tell us what the velocity will be in November or December, but it does let us know that the odds are good these months will have lower velocity numbers than September or October.

Velocity as a Measure of a Complex System

This is ultimately quite significant. Velocity, while a simple concept, is actually a measure of output for a complex system. Think about the number of factors that go into a velocity measurement. There is the organizational mission, the broader business objectives, and the objective of the product itself. There are product owners, designers, architects, developers, testers, subject matter experts, security specialists, database specialists, governance, and production specialists involved. There are standups, planning meetings, and retrospectives. There are epics, stories, and tasks all tracked on a board or in a system with multiple lanes representing different key states in the delivery of each single piece of work. After all these individuals interact with one another, responding to change, and collaborating with the customer in pursuit of working software, we take a single measurement. That single measurement represents the interactions of the individuals and all of their adaptions to change in the delivery of working software.

Velocity is a simple measure of a very complex system.

To measure creative work by throughput alone is to not measure it at all; quality and impact are essential.

While a simple measure of a complex system may sound ideal, in this case, it is generally insufficient. Velocity doesn’t tell us enough to be particularly useful. From velocity alone one cannot ferret out root causes. On cannot determine conclusively that the team is doing better (or worse) from a rising (or falling) velocity.

Velocity is but one dimension to consider. To measure creative work by throughput alone is to not measure it at all; quality and impact are essential.

Velocity By Way of Analogy

So if we know that velocity is a lagging indicator of a complex system, we can probably reason about velocity by way of analogy. There is something we all have in common that is also a lagging indicator of a complex system — our body weight.

Our body weight is a lagging indicator of a complex system. There are inputs and outputs and there are multiple factors that impact the system overall. From our diet and exercise to genetics and even our social network, there are numerous factors that impact our body weight. As we’ve covered, the same is true for a team’s velocity. Multiple factors impact a team’s velocity.

By body weight alone, can we tell if an individual is healthy?

If I were to tell you our patient’s name is “Pat” and their body weight is 130, could you tell me definitively if Pat were in good or poor health? What about a body weight of 100? What about a body weight of 300? If Pat is a linebacker for the Detroit Lions, 300 pounds might be a perfectly healthy body weight. So the answer is, no. Body weight alone cannot reliably tell you if the individual is healthy.

Moreover, if the body weight were in a range that strongly suggested poor health, say 600 pounds, you could not ascertain from the body weight alone what to do for this individual to help them shed weight in a healthy manner.

The same is true of velocity. Knowing a team’s velocity cannot reliably tell you if the team is “healthy”. Adding to the challenge is the fact that velocity has no baseline standard. There is no commonly accepted range within which velocity falls, so our assessment of health gets even more difficult. It is common to see a team with a consistent velocity of 100 or more points per iteration being outperformed by a team with a consistent velocity of 30 points. Points don’t translate from team to team, save basic trending. In general, more points is more software delivered and fewer points is less software delivered. This is assuming, of course, that you don’t point tasks and other noncreation work. If you do that, you’ll likely see little to no correlation between velocity and delivery of software.

Knowing a team’s velocity cannot reliably tell you if the team is “healthy”.

Now we do know that a velocity of 0 is generally an indication of poor health. And just like with bodyweight, while we know the patient is in poor health, we don’t have enough data to make an informed recommendation for improvement. We can say generic things like, “Go on a diet”, or, “Focus on getting to done”, but we cannot provide specific targeted advice with the information we have.

We’ve shown that the measure itself is not necessarily an indication of health. And we’ve further shown that even when we can ascertain poor health, the measure does not tell us enough to diagnose the actual problem. As a result, we cannot make a solid recommendation for how to get to good health.

Now, let’s continue with this analogy just a bit more.

Let’s say that you wake up one morning and you decide that you want to lose 15 pounds. You used to weigh less and you’re tired of the number you see on the scale.

Take a moment and think about all the ways you might go about losing 15 pounds.

Perhaps you would increase your daily step count or take up jogging. Maybe you’d cut back on carbohydrates or you’d increase your intake of salad. You could reduce portion sizes or stop snacking at 7pm each night. Cut back on sugars, replace soda with water, take up crossfit, train for a marathon, or stand while you work. There are any number of things you could do that would likely improve your health and reduce the weight.

But if you’re strictly focused on the weight; if you’re not measuring any other aspect of your health such as cholesterol, sugar levels, or cardiovascular endurance, you might make other decisions to ensure you get to the goal body weight. You could starve yourself. You could consume nothing but water for 30 days. You could smoke crack. You could sever a limb.

Sure, some of these seem ridiculous, but that is precisely the point. Let’s say we are using only one measurement of health. And that one measurement doesn’t tell us enough about the system that produced it. If this is the case, then we can’t really determine what behavior improves the overall health of the system nor can we tell which behavior harms the overall system. In general, the less we understand about a system, the more we are likely to engage in behavior that harms the overall system and the less we are likely to engage in behavior that helps it.

Without sufficient data about the system we can neither properly diagnose our ills nor make informed remediation decisions.

Even our “healthy” options for losing 15 pounds are subjective. For some, training for a marathon would be riskier than making no lifestyle change. I suspect many of you feel you fall into that category.

Without sufficient data about the system we can neither properly diagnose our ills nor make informed remediation decisions.

Just as our bodyweight doesn’t tell us enough about our system to inform our lifestyle choices, velocity doesn’t tell us enough about our system to inform our process choices.