The importance of Velocity
I had an interesting conversation about Agile metrics yesterday, and wanted to share one insight. Why is Velocity so important?
Well, first, we should say that in many ways it is not. Honestly. Velocity can be unmeasured, used badly, up, down, sideways, misunderstood. Whatever. As long as the team produces some more Business Value (e.g., software in production) that is seen as a positive multiple to what they cost, that is all the counts. Of course, we customers always want it sooner, but as long as the effort realized good Business Value, then it was not too late. The product helped that customer set; it probably helped society more generally.
Still, in most real situations we also really need Velocity.
First, for those new to Agile, the typical operational definition of “actual Velocity” is the number of Story Points from the stories (features) completed in an iteration, based on the team’s (robust) definition of done. (Describing a robust definition of done is a good topic for another post.)
- Defense: The team needs Velocity because almost surely some manager is going to ask them to do the impossible and go a lot faster (e.g., complete more Story Points in an iteration) than they can go. Velocity is what the team uses to help that manager accept the truth.
- Challenge: While we do not crucify the team based on a demand for magic, at the same time, the team needs to be challenged to make their Velocity get faster. This means identifying impediments, and getting them fixed (maybe after management approval, maybe by someone else).
- Justification: “What was it you wanted” is the name of a Dylan song. People forget, managers will lose interest in Agile if we don’t have some data to show them and to explain to them why Agile is important. Velocity is one of those key numbers. It helps explain why good teams, good Product Owners, good ScrumMasters and good coaches are needed. It helps keep Agile from being “the flavor of the month” (if you are persuasive in explaining the numbers).