A couple of iterations ago, our product owner made the comment that he was unhappy with the progress that we were making. As we had exceeded our velocity target on the previous iteration, I challenged him on this. He referred me back to our original tentative plan that came out of our planning effort at the start of the project; we were clearly nowhere near that point.
In the course of the ensuing discussion, it became obvious that we're really using velocity to measure two entirely different things:
- the rate at which the team was completing useful work (and by extension, the rate at which we could plan future work), and
- the rate at which we were making progress toward getting the system we're building into production.
Most of the literature assumes that those two things are the same, or picks just one and sticks with it. In our case, our team had been asked to provide support for an external team, to do its own IT tasks, and to perform a number of other duties in addition to its main function of delivering a system on time. All of the things that we were doing had value for the business, and were important for us to do... and weren't moving us forward toward our goal. If we had been a consulting firm, we would have eaten the IT cost and billed the customer for the other tasks; here, that didn't seem to make sense.
We decided to start tracking two velocity numbers by dividing our story cards into two categories: system features and everything else. We have a blue star stamp that we use to identify the system features, and we keep track of our velocity both overall and in "blue star stories." We've been tracking the fraction of our total effort that goes into completing those stories, and managed to raise it from around 60% into the upper 80s.
The obvious danger is that useful technical work will be thrown out along the way, but we've been reasonably good about not doing that.
