Software development teams don't have it easy when it comes to predicting success. Sales managers look at revenue numbers, marketing teams examine qualified leads, human resources count new hires—but what should development teams look at?One of the predictive metrics for measuring your pace of software delivery is sprint velocity. Calculating this metric doesn't magically make your engineering team more productive overnight, but it does help you better plan projects and set realistic timelines—and that can be a game-changer in Agile/Scrum software development.

Sprint velocity can be a useful tool when used for its intended purpose to roughly indicate the amount of work that the team can accomplish together within a sprint. It is not to be confused with individual capacity. A team participates in estimation exercises that measure the complexity of their work at the backlog item level to approximate the team's velocity.

Below, we'll walk you through what you need to know about sprint velocity. First, let's cover what sprint velocity is (and isn't).

What Is Sprint Velocity?

Sprint velocity is rough measure of what a team can accomplish together during a sprint. In order to estimate the team’s velocity, the team refines their backlog items in a backlog refinement session and estimates the complexity involved in each item based on their understanding of what it takes to get that item to the definition of done. Teams adopt different techniques for these estimates:

• T-Shirt Sizing: T-shirt sizing seeks to keep things as simple as buying a t-shirt (XS, S, M, L, XL). It's a more casual, guesstimate-based measurement, but it keeps things fast and flexible. T-shirt sizing methodology is great when you’re looking at the overall roadmap for a quarter and want to make projections before digging into the details.
  
• Number of Hours (or Days): Instead of converting effort into points, teams often just predict the number of hours a task will take once a team member volunteers to complete the task. Time based estimates are challenging to get right, however they may be appropriate when the work item is small enough and when you know who’s going to be working on the task.
  
• Story Points: Teams assign story points to estimate the complexity of completing a backlog item. A quick, simple story might be worth 1 point, while a more complex story might be worth 5-7 points in comparison. Teams using this method learn about their capacity and strive to complete a specific number of story points during each sprint. Story points are a great methodology to move to once you’ve refined the scope of the backlog item and once the team has taken the time to discuss how they will complete it. The value of estimating is in the conversations that teams have during estimation exercises rather than the actual numbers that they end up assigning.

Sprint velocity simply measures the average output (story points, hours, t-shirt sizes) a team completes during an average sprint. For the purposes of measuring sprint velocity, it doesn't matter which methodology you use — it just matters that you are consistent with your measurements. Measuring sprint velocity consistently over time effectively ensures that teams will be able to settle to a predictable pace of software delivery.

Calculating your sprint velocity is relatively straightforward, but is it worth all the tracking and number crunching? We believe it is.

Without a reliable way to measure your team's capacity and performance, it's hard to track progress and set deadlines. With an established sprint velocity, you can know if your team is getting more or less efficient over time. For example, if your team's velocity has been going up over time (without adding new members), there's a chance your development efficiency is going up.

You can also use your sprint velocity to set more realistic timeframes for your development teams and dependent parties. Having an average sprint velocity to rely on will help prevent overpromising and overwhelming your team while also giving you a data-backed reason for the expected timeframe.

How to Measure Sprint Velocity

Remember, your sprint velocity doesn't have industry standard benchmarks, nor is it a metric that you should be using to compare with other development teams — it should only be used for tracking capacity/efficiency within a team over time. Here's the sprint velocity formula to help get an estimate for yours.

Sprint Velocity Formula (With Examples)

Sprint Velocity = Output (story points, hours, t-shirt sizes) / Number of Sprints

For example, let's calculate the sprint velocity by looking at a few previous sprints:

• Sprint 1: 44 story points
• Sprint 2: 41 story points
• Sprint 3: 35 story points
• Total Points: 44 + 41 + 35 = 120

Using these numbers, your sprint velocity would be 120 / 3 = 40.

When you plan future sprints, you can use this average to estimate how much work you can complete. Knowing your sprint velocity will also help you understand how long a project might take and what sprint backlog items you might be able to add to the queue.

For example, if you estimate a bigger project might be worth 160 points, you can safely assume it will take at least 4 sprints.

If you're new to Agile development and don't have historical data to reference, you'll need to complete a few sprints first. Once you collect more data, you can refine your sprint velocity and predict it with more accuracy. We recommend using an average of the last three sprints to calculate your sprint velocity and determine your current workload capacity.

What Sprint Velocity is Not? Common Pitfalls

Many prolific engineering teams don't actually strictly track their sprint velocity as an explicit metric. Like we said before — it’s not so much the numbers that drive success, but the conversations behind them.

When a team huddles to assign story points or t-shirt sizes, they have important conversations about scope, bandwidth, and project details. They hash out the requirements of the project, how long it’s going to take, potential roadblocks, and what needs to be finished before and after. That’s where the real value of measuring sprint velocity comes from — the conversations.

If the team focuses on having the conversations, and if their work items are sliced to be small enough, putting a story point estimate on the items becomes less important and is in fact not necessary.

Here are a few best practices to keep in mind when measuring sprint velocity:

Some Teams May Never Use It

Many prolific engineering teams don't actually strictly track their sprint velocity as an explicit metric. Like we said before — it’s not so much the numbers that drive success, but the conversations behind them.

When a team huddles to assign story points or t-shirt sizes, they have important conversations about scope, bandwidth, and project details. They hash out the requirements of the project, how long it’s going to take, potential roadblocks, and what needs to be finished before and after. That’s where the real value of measuring sprint velocity comes from — the conversations.

If the team focuses on having the conversations, and if their work items are sliced to be small enough, putting a story point estimate on the items becomes less important and is in fact not necessary.

Here are a few best practices to keep in mind when measuring sprint velocity:

Understand the Variable Nature

Your sprint velocity is just an average estimate — it can change year to year and sprint to sprint. Several factors can impact your sprint velocity, such as:

• Holidays
• Vacations
• Sickness
• Turnover
• New hires
• Burnout

Your team might have a few stellar months in Q4, but might be slower when the new year rolls around—that's the variable nature of work. While you can do your best to estimate it with sprint velocity, it'll never be set in stone so long as living, breathing humans are associated.

The more data you can collect about your team's rate of work over several sprints, the more accurate you can become with your sprint velocity estimate. Remember, sprint velocity is an analysis of the past to provide a prediction for the future—it's not a guarantee.

Don’t rely on sprint velocity alone to measure productivity. Consider that team productivity is impacted by more than one facet. Check out the SPACE framework for a more holistic approach to developer productivity.

Sprint Velocity Isn't Universal

Sprint velocity isn't a metric you can carry with you from business to business or team to team. Even estimates do not translate well between teams unless teams have taken the time to estimate together. In Large Scale Scrum (multiple cross-functional, cross-component teams working together because they all have a goal to deliver one common shippable product at the end of a common Sprint), this activity happens during multi-team product backlog refinement. Too many different variables influence this number to allow for apples to apples comparisons across teams.

Optimize Your Sprint Planning

Effective sprint planning is the key to success. Follow the agile methodology by planning for the future but not too far in advance. Understanding detailed tasks for the next 1-2 sprints combined with loose expectations for the next 4-5 sprints will help your team better prioritize projects and clear obstacles before it's too late.

Teams should perform estimates together to avoid a senior lead anchoring the team down with their personal evaluations of the estimates. The team can discuss how long they predict each task will take, and this will help balance the tasks more accurately and evenly.

Improve Your Sprint Retrospective

Retrospectives are critical for teams to learn and grow together and continuously improve.  Take time at the end of the sprint to see what worked and what didn't. What slowed down your delivery, and what helped speed it up? Can you replicate any success and make improvements to enable smoother execution in the next sprints?

Process and tooling improvements should be a regular part of your work. Teams should agree together on what improvement items should regularly be added to the backlog and prioritized.

Faros AI for Engineering Operations

Sprint velocity isn’t an end-all-be-all metric for your software development team, but it’s an effective number for measuring bandwidth and setting timelines. If your scrum team uses the agile methodology, it’s an important metric to look at.

However, what’s more important than a single metric is having a holistic way of measuring performance. You need to look at more than just velocity to understand your output and outcomes.

‍
With Faros AI's DORA metrics dashboards, you can easily measure and track industry-standard KPIs for software engineering velocity and quality, and leverage personalized insights to drive meaningful improvements in your DORA performance.

Want deeper insights into all of your engineering processes (from backlog to production)? Request a Demo of Faros today.