You can use velocity as an effective KPI for agile software development organizations. As a leader, you need to frame it right and be disciplined in its use.
There’s a lot of advice out there 1 2 that seemingly strongly advises against measuring velocity in an agile development setting. And from experience, they’re not wrong at all - I’ve seen how leaders can misunderstand and misuse velocity with very bad outcomes.
There is, however, a way that velocity can be a very useful metric.
Use velocity to measure the development environment. Do not use velocity to measure a team.
Developers love working in environments that support their productivity - low overheads, great tooling, fast build times, effective test suites, cohesive codebases, fast deployments to production, and effective observability.
All of these attributes of your environment have a massive effect on velocity (or conversely, wasted overhead). Often though, teams do not spend enough effort optimizing them as they tend to focus solely on writing the software.
Measuring velocity (which is the product of the environment and the team), and pairing it with other health metrics such as release frequency, build times, shelf time, you can really show the impact and improvement that investment in the environment they work in pays off.
Measure the velocity, and set goals to increase it over time, but focus on improving the environment.
As a leader, ask yourself and your team “What can we do to support you better in the next sprint?".
- Look at the frictions in recent sprint. Maybe build times were too long, or tests were flaky. Maybe you can improve communication across teams.
- Look for interruptions to flow. Were there incidents that popped up? Was there gaps in the goals for the sprint that took time to clarify?
- Look for opportunities to be leaner. Did you build too much? Was the design too complex for this iteration?
Avoid the common pitfalls of traditional velocity measurements.
Don’t equate velocity with hard work. Trust your team that they work hard all the time and use velocity as a way to see if their hard work is being effective in your environment. Maybe a useful analogy is the team is the engine, but if your tires are poorly suited to the environment, all the output is wasted in spinning wheels.
Don’t use velocity for capacity planning or estimation. It can be volatile, but in the end, software developers tend to build new things that they’ve never built before. In this case, past history is a poor indicator of future performance. Besides, you should get started sooner and use forecasts for estimates instead.
Don’t worry about gamification of velocity. Sure, teams may tend to create smaller stories that are easier to complete, but isn’t that a behaviour we want to promote anyway? Trust your teams like the mature people they are.
Don’t compare across teams. Absolute velocity measurements aren’t comparable once taken outside of an environment. That said, it’s perfectly fine to aggregate (sum) velocity from teams in a department, or showcase a percentage improvement over time.
Use Velocity for good, not evil.
- Trust your teams. They work hard and they don’t cheat on metrics. They crave a frictionless and productive environment.
- Focus on the environment. Remove what is causing friction and add things that amplify their effort. Individual performance management has nothing to do with velocity of a team.
- Be aware of the pitfalls and why teams may have bad feelings towards velocity. Address them and show through your dialog and actions that it can help them.