This blog post is part of the series – Rethinking Metrics: Avoid These Common Pitfalls in Measuring Software Engineers.

Velocity is often used in the world of software development and is often a go-to team performance metric. In its basic sense, velocity calculates the number of story points completed in a sprint. As a planning tool, it can be quite useful. While it can be a useful planning tool, relying on velocity as a performance metric for individual engineers or teams can introduce several pitfalls. These pitfalls can do more harm than good.

The Origins of Velocity

Velocity was initially intended to be a team-level metric, used within Agile frameworks like Scrum. This allows teams to gain insight into how much work they can complete in a sprint and to calibrate their workload accordingly. However, the simplicity of the metric encourages organizations to abuse it as a measure of productivity.

Pitfall 1: Encouraging Quantity over Quality

While velocity can be a helpful performance metric, it can lead to engineers focusing more on finishing more story points than on doing quality work. Such situations will lead to technical debt, and general deterioration of code quality. Engineers may also stop taking on complicated but important work that doesn’t produce a lot of story points.

Pitfall 2: Misaligned Incentives

The definition of the story point can vary greatly among teams when it comes to complexity, effort or risk. When velocity is compared across teams or individuals it leads to unfair comparison and misaligned incentives. One team may exaggerate story points to create a “fake” velocity, another one may downplay story points to maintain consistency.

Pitfall 3: Ignoring Contextual Factors

Velocity does not factor in external elements like:

• Ad-hoc bugs or incidents that can’t wait.
• Collaboration around non-ticketed work, such as mentoring, working on a whiteboard, or writing documentation.
• Variability in tasks, where a single, highly impactful feature might take more time but doesn’t align with the velocity model.

These contextual nuances are crucial to understanding an engineer’s true contribution but are invisible to these velocity metrics.

Pitfall 4: Fostering a Culture of Competition

When velocity is tied to individual performance evaluations, it can foster unhealthy competition. Engineers may prioritize individual tasks over collaboration, undermining team cohesion. This siloed mindset can lead to inefficiencies and a lack of shared ownership.

Conclusion

Velocity was never intended to measure individual performance, and yet this is how it is most often used. When misused, this can cause bad habits, poor quality of code, and ultimately lose focus on customer value. By rethinking metrics and prioritizing a holistic view of contributions, organizations can foster a healthier, more productive software engineering culture. Let’s move beyond velocity and measure what truly matters.