Archive for the ‘Metrics’ Category.

Velocity—it ain’t what it sounds like

In the physical world, velocity is a common and well-understood term. In the world of Agile software development, “velocity” means something that, at first glance, seems similar to the physical world meaning, but which is in fact different in an important way.

Velocity in the physical world

Anyone who drives a car is intuitively familiar with the meaning of velocity. It means speed, and is commonly expressed in miles or kilometers per hour. A slightly more abstract expression would be some distance per some unit of time. An even more generic way to say that is the ratio of benefit to time (benefit/time).

In the physical world, whether from the point of view of a commuter, a cabbie or a race-car driver, increased velocity means increased value—in more technical terms, that’s an increase in the benefit/cost ratio. In these cases, the benefit is miles traveled. Time taken is the cost.

To the commuter, traveling a fixed number of miles in less time provides increased value by lowering the time required to get to or from work.

To the cabbie, who effectively gets paid by the mile, covering more miles in a shift provides greater value.

To the race-car driver, winning the race has more value than coming in second.

Velocity in Agile software development

People engaged in Agile software development also use the term “velocity” and, probably because of the physical world meaning of the term, can be inclined to believe that increasing velocity means increasing value (or benefit/time), just like it does in the physical world.

Velocity in software development is typically expressed in terms of (story) points per iteration. At first glance this seems very velocity-like—something delivered in some period of time. But a closer look at what is being delivered reveals something interesting.

Story points don’t represent benefit

Many agile teams use relative estimation in one form or another to project how much time it will take to develop various functional bits (user stories) in a product. It’s common to assign a number of points to each story being estimated. In relative estimation, when we estimate a story at 3 points, for example, we’re saying that we believe it will take 3 times the amount of time to develop that story as a story estimated at 1 point.

So let’s say that we work in 1-week iterations, and at the end of a week we total up the estimated points for all the stories we completed that week and find that we completed 25 points worth of stories. We call that total our “velocity” and we use that velocity figure (25 points per week) both to project future completion dates and to determine how much work we think we can do next week.

But what we call “velocity” in software development isn’t like velocity in the physical world, in that points don’t represent a benefit. At best, what we call “velocity” is actually only a ratio of relative time to absolute time. It’s a useful ratio, to be sure, but only so far as it lets us make calculations that convert our estimates to actual (calendar) time. Multiplying “velocity” by the number of weeks remaining until a deadline tells us how many points worth of stories we can expect to complete. Dividing the total number of story points in our backlog by “velocity” yields the number of weeks remaining until anticipated completion.

What we call “velocity” in software development doesn’t represent a benefit/time ratio like it does in the physical world. The largest implication of this is that increasing velocity does not necessarily translate to increasing value.

What’s in a name?

It’s important what we call things. The term “velocity” is certainly more convenient than something like “relative to absolute time factor” but it can mislead if not well understood.

Have you been in a situation where you’ve been encouraged to “increase your velocity”? It’s almost certain that the person doing the encouraging was really asking for you to go faster—to increase the benefits delivered in a certain amount of time.

In hindsight, it would probably have been better to use the term “velocity” to describe a benefit/cost ratio, like it does in the physical world. One of the easiest benefits to understand, at least in a for-profit company, is revenue. Revenue is a benefit, and time is a cost, so revenue/time is a reasonable way to express velocity. Or would be, if the term didn’t already have an accepted meaning.

We may have to live with the term “velocity” to describe what is actually only a “time factor.” After all, we’ve got roughly a decade’s worth of inertia supporting this now-traditional usage.

But we can at least be aware, and strive to make others aware, that increasing velocity isn’t something to aim for. Try increasing value instead.


Defining developer productivity

Can you measure the productivity of an individual developer or team of developers? Do you really want to? If the answers to these questions are “yes”, the first thing you’re going to want is a clear definition of productivity.

(I was inspired to write this article by a thread in the scrumdevelopment Yahoo! group titled Executives Tracking Individual Developer Productivity?  The originator of the thread wrote about a real issue in his company that had to do with the CEO wanting to measure the productivity of the company’s developers based on the principle that  “you can’t manage what you can’t measure.”)

Productivity good!

We can probably agree that productivity (in the abstract) is a good thing, but can we agree about what it means concretely? For starters, what are the “units” of productivity for individual people or teams?

For example, we can compare the gas mileage of vehicles to each other in units of  “miles per gallon”, and we would probably agree that vehicles with higher numbers are more productive.

What units could we use to compare individuals or teams in a similar fashion? One commonly-employed notion from our past, and one that we have thankfully left behind, is that developer productivity could be measured in lines of code produced in a given period of time. But if that’s behind us, what are we left with?

Productivity defined

The business novel The Goal defines productivity as follows:

“Productivity is the act of bringing a company closer to its goal. Every action that brings a company closer to its goal is productive. Every action that does not bring a company closer to its goal is not productive.”

Sounds simple enough. Now all we have to do is to figure out what the company’s goal is, and we’re there.

Do you know what your company’s goal is? Not its mission statement, but its goal? Is your company in business for a profit, or do you work for a non-profit concern? Most of us, I believe, work for companies interested in making a profit. And if that is so, then most companies’ goals might very well be as simple as making a certain amount of profit per year.

But we’ll probably want to measure the productivity of our developers more frequently than once per annum, so we might express the productivity of an individual or team in terms of “profits earned per iteration”.

The thing is, can we actually measure the contribution to profits made by an individual developer or even a team of developers? Offhand I’d say that this is a difficult proposition, at best.

However, I contend that if we cannot correlate the productivity of an individual or team with profits, then there really isn’t much point in trying to assess that productivity in the first place.

Looking where the light is better

There’s on old joke about a man who is searching the area around a corner streetlight. A second man comes along and asks him what he’s doing, and the first man replies, “I’m looking for a quarter that I dropped.” The second man joins in the search, but neither man is able to spot the lost coin. Finally the second man thinks to ask, “are you sure you dropped it here?” The first man replies, “no, I dropped it in the alley, but the light’s better here.”

In a for-profit company, attempting to measure the productivity of a developer in any terms other than contribution to profits amounts to looking where the light is better. In other words, don’t measure something just because it’s convenient to measure.

Clicky Web Analytics