Sprint Velocity Considered Harmful

In the last month, I had at least three people tell me that their team's performance is measured by their Sprint Velocity. When the number of Story Points delivered goes down, it implies that the team is not performing well. Is that the right metric to measure performance? Can team performance be so easily measured with just this one metric?

"Velocity" is a term that has undergone semantic diffusion just like many other terms used in tech. It's very natural to incorrectly assume that velocity == speed == performance.

Semantic diffusion occurs when you have a word that is coined by a person or group, often with a pretty good definition, but then gets spread through the wider community in a way that weakens that definition. This weakening risks losing the definition entirely - and with it any usefulness to the term. - Martin Fowler

Velocity was designed to be used as a capacity planning tool. It can be used to extrapolate and forecast how long it will take the team to complete all the work that has been planned and estimated. When used it as a way to measure a team's performance or even to compare teams, it loses all meaning.

Flaws of using velocity as a performance metric

• Velocity is a relative and not an absolute measure.
• Velocity is team dependent. Each team has a different context, and velocity can't be used as a common measurement.
• Teams might start to hack their velocity by inflating estimates.
• The focus might shift on completing as many stories as possible at the expense of quality.
• Focus on delivering story points could lead to less collaboration across teams.
• Teams would reach 100% utilisation with no space or time to think, learn and improve. There's no capacity to consider unplanned work or make changes to the plan defeating the core purpose of Agile Software Development - being able to react quickly to change. This results in longer lead times.

Queue Theory in math tells us that as utilization approaches 100%, lead times approach infinity—in other words, once you get to very high levels of utilization, it takes teams exponentially longer to get anything done. - Accelerate

Use velocity for forecasting

As the team's estimates start getting more precise with each iteration, use velocity to plan and re-prioritise tasks as time progresses. Use it to identify potential risks in missing deadlines and make necessary changes. Project management tools like JIRA make it quite easy to visualise and manage.

Better ways to measure performance

Here are some more interesting and valuable ideas to measure software delivery performance:

• Delivery lead time - hours, days, weeks
• Deployment frequency - on demand (multiple deploys per day), weekly, fortnightly, monthly
• Time to restore after a failure - less than one hour, one day, multiple days
• Change failure rate - < 15%, 30%, 45%

Adopt Continuous Delivery principles. Check out the State of DevOps Report each year.

Walk away from ignorance

It's very useful to learn about Agile and understand that is not just about project management. Agile was produced from the amalgamation of the XP, TDD and Scrum communities. Agile talks about things like "metaphor", that was taken to the next level by Eric Evans' usage of Ubiquitous Language in Domain Driven Design. Just working in Sprints/iterations doesn't make you Agile. Good Agile practices have a lot of impact on the quality of code, software delivery and overall team happiness. When the Agile Manifesto was written, the web wasn't as big as it is now. Software has evolved quickly and so have the principles.

Go back, read your books and challenge your managers.