I’ve seen teams “game” velocity, doing risky things (like letting unit testing slip and quality drop) to keep their velocity high. It didn’t occur to me that part of the problem might be terminology. Tim Ottinger’s “Velocity is Just Capacity” (stale link, but here’s Tim’s later thinking) gave my thinking a serious nudge.
“Velocity” evokes speed and quickness. Speed and quickness are good. Speed and quickness win races and awards. A manager whose team has a high velocity is a winner. Recall Mike Cohn’s advice to alway append “billion” onto any velocity number that you give to a manager so that they can one-up their peers.
But consider the reframe: A team has a demonstrated “capacity” for taking on work. The prior iteration (or a weighted average of the past few iterations), establishes a Load line (AKA “Plimsoll line”) around the team. Load is a measure of capacity. It’s velocity as Agile uses the term, but without the baggage of evoking competition. Discussions about increasing capacity are subtley different from discussion about increasing speed. Tim lays it out nicely in his article. I think he’s on to something.
Is a terminology shift all we need to drive out bad velocity behavior? Sadly, no, but I think it would be step in a good direction.