What does velocity measure? Does measuring velocity help? Does it hurt? Does it help more than it hurts?

First, let’s be clear: by velocity, I mean story points delivered per iteration over time. Of course, that means we need more definitions, so let me get those out of the way now.

Listen To the Words Coming Out of My Mouth…

“A story point” is a unit that programmers invent solely to make it easier to estimate the work it takes to deliver a story. A story point is however big the programmers decide it is, no more, and no less. Story points are useful to the extent that they help programmers compare the effort required to deliver different stories, so that the team can decide how many stories to commit to delivering in a given iteration. Although story points necessarily fluctuate in value, one hopes that over a sufficiently short span of time – say the length of a release – the fluctuation is small enough that a constant approximation of velocity is helpful enough to plan the release.

“Delivered” means realizing (in the accounting sense) the value the customer intended to realize by asking the team to work on the story. A story is not delivered until it either reduces cost or generates revenue.

“Iteration” means equal-length time boxes the goal of which is to provide natural breaks in daily work to reconsider the plan and stop work from expanding indefinitely. On teams that have less trouble stopping when they’ve done enough, iterations are less important.

“Over time” refers to the trend of spot measurements over at least the length of a release.

I hope that makes it crystal clear what I mean by velocity. Now that I’ve clarified the meaning of velocity, what does it measure? It simply aggregates past estimates of effort of a set of stories the team selected to complete in the last several iterations. That doesn’t sound like much, does it? There’s more. Here are some things that velocity does not measure:

  • productivity
  • efficiency
  • value
  • suitability to re-hire or retain

…and, of course, past performance does not guarantee future results. Read your prospectus before investing. If velocity is so meaningless, then why measure it? Well, it turns out that:

  • It is a good approximation (accurate about 2 times in 3, we think) of what the team can commit to in the next iteration
  • It is a good approximation (we think) of what the team can commit to over the next handful of iterations (say 4-6)
  • It is a good approximation of when the current stack of work we’ve identified will be done, as long as the stack of work isn’t too large (up to about 4-6 iterations’ worth)

The Trouble with Measuring Velocity

I have just witnessed a conversation on the extremeprogramming Yahoo! group that illustrates the knots in which we tie ourselves when we allow ourselves to be too imprecise about what a measurement measures. The whole thing puts me in mind of personal financing and when budgets don’t work.

Think about budgeting your expenses at home: you know how much you actually pay for some expenses, like car payments, mortgage or rent, insurance… the amounts you owe are usually spread out over such a long period that you can anticipate what you’ll owe next month with certainty. Moreover, you know that it takes concerted effort on someone’s part, or human error, to change the amount you owe on a mortgage, car loan or your home insurance. Changes in those amounts, at least correct ones, generally don’t sneak up on you.

There are other expenses that vary from month to month: food, clothing, entertainment, communications… the amounts you owe usually depend on how much of a given resource you consume, such as how much you eat, how much you talk on the phone and how stressful your work is that month. You can budget these amounts fairly accurately, because the variation is low enough and mostly under your control: you can choose to eat less, take better care of your clothes, read more library books and rent fewer movies. Not only is it easier to guess what you’ll spend in a given month, but if you start spending too much, you can easily correct course to spend less.

There are still other expenses that you just can’t foresee. You are injured in an accident and rack up $20k in hospital bills; this is the year out of the last ten that you finally need new shingles on the roof; you find out your son needs braces. You might buy insurance as a way of smoothing out the costs over time, but they are generally big expenses that you know are coming in the larger sense, but which arrives without warning and needs to be paid immediately.

These are the expenses that make budgeting not work, because they prove that there’s no such thing as a typical month. This is also why you cannot rely on velocity to plan far ahead: there is no such thing as a typical project or even a typical iteration. If velocity doesn’t bring a project under control, then what might? For an answer, I invite you to consider personal finance again.

Measuring Personal Financial Velocity Saved My Life (Really!)

I read Your Money or Your Life to help me bring my personal finances under control and become financially free. One of the key exercises the book asked me to perform was to track all money coming in and out of our household for several months. This exercise is designed to call attention to our spending habits, so we can decide what to do about them. In particular, we identified those expenses we valued and those we didn’t value, so we could stop spending money on things we don’t value. This tactic, spending money only on things we value, doesn’t necessarily make one rich, but it ensures that one is not wasting money on things one doesn’t actually value. You’d be surprised how much money we were throwing away on things that didn’t ultimately make our lives any better, and you’d be amazed at the results when we stopped: we used that money as capital to generate passive income, and within five years, we’ve become financially free. But I digress. The point is what we measured, then how we analyzed it.

We measured actual spending, rather than estimated future spending or even estimated past spending. When we had the numbers, we didn’t start slashing expenses we cared about, and we didn’t start looking for cheaper alternatives to all our expenditures. Instead, we simply looked for those expenses we did not value, then cut them off. In some cases, this required investment of money: we bought a coffee grinder, an AeroPress, then started brewing coffee at home, rather than spending $2 per on coffee at our local coffee shop. In some cases, this required investment of time: we reviewed our work commitments and changed the way we work so that we wouldn’t be so tired so often, which meant we no longer “needed” to order dinner in as often as we did. We measured our actual spending, we looked at those numbers to identify waste, then we eliminated it. We did not waste effort staring at our budget, wondering how accurate it was, wondering how realistic it was, desperately trying to spread not enough money over too many expenses. We didn’t have to: we had actual expense numbers and could decide which items we valued and which we didn’t. More to the point, this exercise was far more instructive and effective than budgeting ever was.

I Value Budgets Over Estimates

Very, very ironically, I prefer not to bother estimating small bits of software development work (things smaller than a few months’ effort), but rather, think about budgets for those bits of work. I’d rather say “We can afford to spend a week trying to build this” than “I hope/guess/think/believe that it’ll take a week to do that”.

When we try to guess the cost of the task, then we get that wrong, everyone fights. This wastes energy all around: they feel bad, they yell at us, we feel bad, then we yell at them for demanding estimates even though we didn’t have the information we needed. Circle of pain.

When we set an investment budget for a feature, we can change course when it becomes clear that we won’t deliver what we wanted for the original “price”. We can try to build something smaller. We can try to ship the most valuable parts. We can negotiate what deficiencies in the solution we’re willing to live with for the moment, in order to get some value out now. We have more information with which to estimate the work remaining to get the originally-intended version of the feature. We can say things like this: “We have 2 days left. We can definitely deliver this slower version of the feature, which would annoy maybe half the users, but still delight the other half. We’re still not clear on how long it’ll take to deliver the faster version, but probably not less than another week, because of this third-party library isn’t working the way we expected, and we might have to dump it and find an alternative. If you want to wait for the faster version, should we spend the extra 1/2-day to deliver the slower version first, or do you prefer not to spend that 1/2-day and wait for the faster version?”

Of course, we can have that conversation even when we estimate costs the way we’ve been doing, but when we focus on estimating costs, I see a lot more yelling and when we focus on budgets and investment, I see a lot more negotiating. You might see it differently.

Maybe You Just Don’t Need Velocity Right Now

Does your company value the areas where your software team spends its money? Do you know how to measure the value of what your team produces? How much money (time, energy, or actual cash) does your team spend on things that no-one values? Could you pick three sources of waste and eliminate them? What would you do with the recovered time, energy, or cash? How would you know that things got any better?

Forget velocity for the time being. Measure it and report it to whoever still wants it, but just between you and me, forget velocity and focus on these key questions. Try it for a few months, then tell me how it goes

Updates

Updated 2012-06-13. I read a tweet today that shows that someone, somewhere, understand what I mean.

Updated 2012-10-12. I read an article by Joshua Kerievsky, one of the most experienced practitioners in our field, on this very subject, and I strongly recommend that you take several minutes and read it yourself. Click here.