Every software team faces a big question: how do we measure success? Sure, your team writes some code. They review some pull requests. They might run some tests. Finally, they ship some software. All of that is great. To the software team dedicated to continuous improvement, that process still leaves questions: Were they successful? Could they have done a better job? How did this software deployment compare to others? One way that agile software teams measure their performance to answer some of these questions is by measuring their sprint velocity, which is what I’ll be detailing in this post.
Sprint Velocity: What Is It?
To understand what sprint velocity is, it’s important to first discuss sprints. Software teams split their development cycles into discrete chunks of time that they call sprints. Each sprint has a well-defined list of tasks to accomplish, and the team commits to finishing all of them within the sprint window. That’s usually two weeks, but some teams adopt sprint windows that are only a week. Others dedicate as much as a month to a single sprint. There’s no specific time window. The key is that each sprint is exactly the same length.
So, put simply, sprint velocity is a measure of an individual team’s rate of work during an average sprint. Before the start of a sprint, a team looks at all of the tasks they’re committed to finishing and estimates the complexity of each task. The mechanics of that estimation vary from team to team. Many teams adopt story points, which are made-up numbers that represent nothing but one task’s relative complexity among the work assigned to the team. Some teams skip abstract story points and directly estimate the number of hours they’ll need to complete a task. Other teams skip numbers completely and adopt a T-shirt sizing method of estimating complexity.
Sprint velocity, then, is the measurement of the average number of story points or hours of development work or T-shirt sizes the team completes in the average sprint.
Key Things to Know About Sprint Velocity
If you’re just beginning to use sprint velocity as a metric for your software teams, there are several things to understand about it.
Velocity Is Descriptive
As a software developer, this is probably the #1 thing I wish more managers understood about sprint velocity. It’s a descriptive metric, not a prescriptive one. To put it a different way: measuring a team’s sprint velocity is like measuring the average height of each of the team members. Once you’ve made those measurements, that height is an innate attribute of the team. You wouldn’t come to your software team and tell them, “Our goal is for every person on this team to be 6’3″ tall.” That would be an absurd way to try to manage the team. Sprint velocity is a similar measurement. It will tell you about how tall the team was at a given moment, and allow you to compare between sprints completed by the same team.
The key thing to remember about sprint velocity is that it’s a measurement of how fast the team went in the past, not something that will tell you how fast they’re going to go in the future.
Sprint Velocity Is Variable
I recognize that this seems like a contradiction from the idea that sprint velocity is an innate attribute of the team, but hear me out. The members of each sprint team are people. People have better and worse days, and better and worse weeks. They get sick, and they go on vacations (which you should encourage, as a leader). To return to the height metaphor: not everyone stands as tall as they can all the time. Sometimes, a person needs to crawl around on the ground to try to find something they dropped. The key takeaway is that looking at one individual sprint’s velocity is often too small a picture.
The team’s completion rate for an individual sprint isn’t necessarily a good barometer for how long they’ll take to complete a project. It’s the same as with a car: knowing how fast the car is going in any five-minute period isn’t a good way to figure out how long it’ll take you to drive cross-country. Instead, you want to find the average number of miles traveled per day or week to figure out how far away your goal is.
Increasing Velocity Is Difficult and Counterintuitive
Every single agile team I’ve ever worked on has had a conversation about increasing velocity at some point. As a developer, this isn’t surprising. We understand that when managers see a metric, their first impulse is to try to optimize it. The natural impulse for the business as a whole is to want more features more quickly, with fewer bugs. So, the manager, responding to the pressures of the business, tells the team that they need to work faster. In my experience, this is usually a self-defeating goal, because the team switches focus from delivering software to figuring out why they aren’t delivering more software. Instead of writing and reviewing code, the team sits in meetings discussing why they’re not getting more work done.
Counterintuitively, the best way to increase sprint velocity is often to spend less time thinking about it. Instead, spend more time focusing on writing quality software and ensuring the team encounters the fewest roadblocks possible. To return to our cross-country road trip analogy: spending time talking about how far you need to go isn’t productive while you’re stuck in traffic. Often, it’s going to do nothing but create stress, which leads to wrong turns, slowing the trip down even more.
Sprint Velocity Is Arbitrary
This is another key to understanding sprint velocity. Most teams can tell you their velocity pretty quickly. For instance, the team I currently work on averages about 44 story points per sprint. That’s a stable velocity: we tend to be within three to four points of that number on either side every sprint, going back eight months. Do you know what it would take to double our sprint velocity? We could do it overnight. All we’d have to do is double our pointing estimate for every story we take on. Instead of completing 44 points per sprint, we’d finish 88, overnight. Would that put us any closer to a distant goal? Not for a second. Would it look really good to an executive? It might!
Just like if we started measuring our road trip in kilometers per hour instead of miles per hour so that it’d look like we were going faster initially, sprint velocity isn’t an absolute truth. Many teams, when pressed to increase velocity, will simply start padding estimates. They start meeting their sprint commitments more consistently and they see a bigger number on a dashboard, but they don’t ship any more software. This is why sprint velocity is a dangerous metric for a sprint team.
Don’t Abuse the Velocity Metric
Sprint velocity is a useful metric. It gives context to the work done between individual sprints by a single team. That’s a handy tool to have. But it’s important to remember not to abuse that metric. Don’t use it for things it isn’t made to measure, and don’t trust it as an absolute truth. Instead, focus more on better metrics, like software development cycle time. Remember that your goal isn’t to juice a metric. Your goal is to ship the best software you can, as consistently as you can. Instead, focus on sprint velocity as a descriptive measurement of your team, which tells you how much work they finish, on average. Use this to plan your team’s capacity, but recognize that velocity is a variable metric. It’s influenced by many outside factors, and even when it goes up, it doesn’t necessarily mean you’re reaching your ultimate goal any faster. Keep those key learnings in mind, and you’re on your way to unlocking a sprint team’s true potential.
Ready to start tracking your metrics with a single source of truth to reduce cycle time, increase velocity and improve your engineering processes? Schedule a LinearB demo.