Software Team Efficiency: Team Velocity

We’re rolling out a series of articles focusing on improving the efficiency of a software development team – and debunking agile myths. We’ll start with team velocity: an agile concept that allows you to see how fast your dev team is going. Let’s see how you can get the most out of velocity calculations.

A simple idea that works

To calculate velocity, you’ll need to add up how many backlog items/story points the team delivered in an iteration. One glance can give you a pretty good idea of how development is moving along.

1. You can use it to predict when particular features can be completed, what’s more, you can estimate if you’ll be ready with your backlog.

2. You can monitor project trends. Is there a growing technological debt you should be aware of? Let’s say velocity has jumped unexpectedly. However, are we sure we’re meeting the Definition of Done?

3. You can see how well your team’s getting along. Changes in velocity (or lack thereof) can be a symptom of interpersonal problems. Keep track of all the phases (forming, storming, norming and performing). It’s rarely a steady process. Team rotations can be another problem. That’s precisely why we avoid them at Espeo.

4. It’s also good to pay attention to the velocity of a particular person, especially if he or she is a new addition to the team. Monitor your velocity per person or normalized velocity. Ideally, the addition of a new team member will keep your normalized velocity flat after an onboarding period – when the person gets up to speed and the team tries to accommodate the new member. However, if the normalized velocity remains lower, it’s a situation that deserves a closer look.

Dispelling 3 velocity myths

We’ve listed three typically voiced concerns and myths (they’re on our infographic too). See why these are all wrong.
#1 myth – expect your team’s velocity to decrease over time as the project grows
Wrong: a healthy project should maintain a constant velocity over time or even improve all things equal.

#2 myth – velocity is not a reliable indicator because it’s dependent on too many parameters
Wrong: velocity is flexible and can indicate trends related to the code and the project team. Normalized velocity is used to compare the performance of a team which has grown.

#3 myth – a focus on velocity is going to hinder a project’s quality
Wrong: to maintain high velocity you need to keep your technical debt in check. What’s more, if the tasks you decide to tackle during sprint include refactoring or removing technical debt (or testing), then even ‘chasing velocity’ won’t decrease the quality.