Agile Velocity: Speed or Direction?

I've heard quite a few people make this quip when presented with the concept of "velocity" in an Agile project. They're quite right, as it is rather a nonsense to use the term when the measure we are referring to is a scalar. However, it's rather an established term and I've never let it get in my way: I'm not one of the unlucky people for whom it simply causes a parse error form which I cannot recover.

But I was thinking today (odd, because I spent most of it singing songs to and building cup stacks with my 20 month old son) about whether it would be possible to "expand" the Agile velocity measure a bit and make it a vector. Now this isn't intended to be deadly serious, rather a tongue in cheek attempt to assuage the guilt of using the term velocity when I should know better. With this caveat in place, I'll proceed...

When a project starts, we have a big deficit: our pile of story points; code points; ideal days; whatever we have chosen. We're going to chew through this in a sensible order and keep track of our progress by measuring the rate at which we're doing it. The deficit can change if we re-estimate (not usually a good idea) or there are new features added (commonplace), so the target advances towards us or recedes away accordingly. In addition to the usual changes to the work remaining, I've spent a fair bit of time trying to estimate the additional effort emergent bugs introduce to a project, mainly so I can estimate the factor I should apply to future estimates to account for bug-fixing. If we're being extremely tight in our project iterations, this maybe doesn't really figure, because we're not entitled to knock off the effort for a story until it's passed all user acceptance test and QA. That's fine when it's possible, but it often isn't feasible to go through an entire QA cycle to get feedback about progress if it takes 3 weeks to do so and the project is 8 weeks long. It's also quite difficult for projects on legacy code bases when introducing a new feature potentially causes bugs to arise in different areas. So, the idea I had is to introduce a second dimension orthogonal to the "feature effort": "bug-fix effort".

Velocity is now a 2D vector in "feature effort" vs "bug-fix effort" space! Now, as I've already said, this isn't intended to be taken too seriously and there are flaws. Most importantly, feature effort and bug-fix effort aren't really orthogonal, they are collinear and dependent. To make schedule estimation stand up mathematically, we have to represent the magnitudes of the velocity vector and the distance to the target in Manhattan distance: Euclidean distance would artificially reduce the required effort to complete the project.

However, thinking about the two dimensions of velocity represented in this way could reveal some insight into the way our project is going, for example:

1. During the early phases, the direction is entirely in feature effort and the target is on the feature effort axis: everything's fine!
2. Later on in a project, the target travels in the bug-fix effort direction yet our velocity remains unchanged: maybe this is a warning to start applying some bug-fixing effort to avoid a large "course change" later.
3. We focus on bugs excessively and our heading passes the target to the "sea of bugs" side: perhaps we are losing sight of the main game and will miss the feature target.

So, perhaps there are some indicators for a project manager in this way of looking at things, but I suspect that it's more likely a bit too much of a joke to be useful. But if you're firmly attached to your "velocity" measure and are desperate to shirk the ridicule of the pedants, then be my guest and try it.