Good Velocity?
As many of you know, velocity is a valuable agile metric that allows teams to gauge how much work they can accomplish in a single cadence. Since agile asks that teams estimate the effort required to complete a story rather than the time it will take, teams assign effort estimates to stories, i.e. abstracted valuations which can be expressed as t-shirt sizes, “headaches,” or any other measure agreed upon by the time.
Over at InfoQ, Chris Sims reports on the notion of “good velocity,” inspired by a question Buddha Buck posed to the XP list serve: For a team of about seven, doing two-week sprints, what range of velocity would be considered ‘good’? Amazingly, Buck identifies a ‘bad’ range, explaining that a velocity of eight or less probably means a team isn’t breaking its stories down into small enough chunks.
Now, if a team’s velocity is determined by estimations, using a scale agreed upon by the team doing the estimating, how can an outsider evaluate if the team’s velocity is “good” or “bad”? Certainly, if a team’s velocity increases over time, demonstrating ongoing performance improvements, that’s good. If a team simply gets worse at working together over time, reflected in a waning velocity, then that would be clearly bad. But the notion of a standard or an acceptable range is ludicrous. Velocity is useful for the teams estimating their work—they understand what a “Small” story looks like versus an “Extra-large” one. And depending on how they choose to estimate their stories, a velocity of eight might actually be a hyper-performing team.
So, to summarize, what’s actually important with velocity is whether a team’s velocity increases or decreases. There’s no standard for performance, since there’s no standard of measurement. But a team that does more every sprint should certainly be considered to be within a “good” velocity range.