A Fairly Thorough Guide to Understanding Velocity vs. Capacity

Velocity vs. capacity. These terms are important when it comes to resource planning, and also a little confusing.

But understanding the difference between them is well worth it. Knowing the difference better enables engineering teams to plan development priorities and avoid bottlenecks and inefficiencies. With solid product capacity planning, you’ll actually be able to focus on the work that needs to get done, not the work you all too often spend most of your time doing.

What we’re really talking about when we talk about these two project management terms is this: Can we do the work? Really, though, can we do the work?

Velocity and capacity are the terms you use when your manager asks you to do something. Rather than saying, “Sure, boss!” or “Eh, that sounds hard,” these terms provide the tools you need to give your manager a strong yes or no. And rather than relying on gut feelings, you’re using terms that they respect and understand.

Velocity vs. capacity: What's the difference?

Let’s break this down into basic definitions. Remember these. We’ll come back to them.

Velocity is a measurement of the average amount of story points delivered across a given time period.

Capacity is an estimate of the total amount of engineering time available for a given sprint.

Both of these metrics are based on the concept of relative estimation.

Relative estimation is when you measure tasks in relation to one another, not individually or by absolute units of time. Agile development teams use this idea all the time. Some are explicit about it, but many have taken up this term as the natural, almost unconscious way they do things. It helps to get everything out in the open.

Relative estimation is the core concept behind generating and assigning story points. The whole reason we use story points, instead of some normal thing that non-developers might understand, is that engineering efforts aren’t absolute.

What might be easy for your engineering manager will be hard for you. And what might be a snap for you might be a struggle for a junior developer. It depends on skill sets.

Instead of assuming one task will absolutely take X amount of hours, story point estimation lets developers find common agreement on the difficulty of one story point and extrapolate. Once teams find a task that they agree is worth one point, they can then assign other tasks points in proportion. A two-point task should be twice as hard, a three-point task three times as hard, and on and on.

Relative estimation is foundational for understanding velocity and capacity. Both velocity and capacity avoid working in the raw, absolute area of time or hours.

Instead, velocity and capacity work from the past or in the future.

Let’s go back to those earlier definitions and expand them with relative estimation.

Capacity planning is an estimate of the future; velocity is a measurement of the past. That’s your north star. Capacity is an estimate of the total amount of engineering time available in a given sprint. Effective capacity planning should be based on future expectations of available time, i.e., an estimate relative to the expected future.

Velocity is a measurement of the average amount of story points delivered in a given time period. Planning based on velocity means basing your estimates on past performance, i.e., an estimate relative to the measured past.

How to measure velocity and estimate your team’s capacity

Ideally, capacity and velocity work in conjunction. Velocity measures what a team is doing, on average, over time, and the capacity planning process estimates what a team is actually able to do in the next sprint (whether that be above or below average).

How to measure velocity

Velocity is about measurement. But the math is minimal.

Take the amount of story points your team completed in three past sprints, add them together, and divide by three (the amount of sprints). That average is your basic velocity. The more sprints you add to your velocity measurement, the more accurate your average.

With that data point in mind, you can then extrapolate how many story points your team can complete in the next sprint.

Velocity is based on basic math and basic inference. Once you have the average, you can predict that that’s the amount you’ll likely do in the next sprint, too. Barring extreme circumstances, your velocity will give you a good baseline for predicting how many points you’ll complete in the next sprint.

Capacity planning Strategies

Capacity is about estimation, but the estimate is educated.

Capacity uses velocity, an average, as a starting point. From that baseline, you can build a prediction of how much you can do over the next sprint informed by more immediate circumstances over a time frame.

Estimate capacity by quantifying the amount of engineering time each team member can work in the upcoming sprint after accounting for time off, potential illness, and responsibilities outside of story development (such as maintenance work, PR review, meetings, etc.).

To use them in tandem, find your velocity from your past sprints, and then adjust that average based on expected capacity from your current vantage point. Any given sprint might be above or below average; the key is using the information you have to make as accurate a prediction as possible.

Get team-wide buy-in on team-wide metrics

The choice to measure is not a decision you should make lightly.

Metrics shape the workflow of your team, demonstrate what success and failure look like, and determine what your team will be thinking about most days.

If you don’t get buy-in on what you’re measuring, your team will resist those estimates and morale will drop. Low morale means an unhappier, less productive team, as well as predictive metrics that are even less useful over a period of time.

It’s essential to consider capacity planning tools as predictive tools, not punitive tools. That means you should use them to plan for the future, not criticize what happened in the past.

Measuring your team’s performance by these metrics is risky because it can encourage the wrong incentives. Development teams work best when they’re focused on core work, not metrics. Between sprints, ensure the aim of your focus is true:

• Focus on delivering value, not on hitting arbitrary goals
• Focus on making progress, not checking items off a list
• Focus on incremental improvements to the big-picture product, not creating and measuring the results of a feature factory
  

Velocity and capacity management go wrong when someone ties them to time or performance. They’re only for planning and, even then, only for our best attempts at planning.

Velocity and resource capacity planning help you make realistic estimates for how tasks change over time with projected demand. If you tie those metrics to absolute hours (i.e., telling a developer that X task takes Y hours and not an hour more), then you can’t account for how that task will evolve over a given period of time. Worse, if you punish developers for not living up to their best guesses, then you encourage them to make conservative estimates of their abilities.

Then nothing would be accurate, and no one would be happy. So don’t do that.

Measure with purpose and avoid measurement theater

If you don't measure with purpose, you end up with measurement theater. What's measurement theater, you ask? First off, it's the last term I'm throwing at you in this article. Second, it's important for making sure your metrics are meaningful and helpful.

We can't talk about measurement theater without first considering the work of John Cutler. John is head of product research and education at Amplitude and has written extensively about project and product management writ large. He popularized the term “success theater,” a concept I'm going to borrow and adapt. Success theater is when success decouples from the meaning of success, when teams celebrate doing tasks or projects without thinking about what they mean.

Measurement theater is its evil(er) cousin. Measurement theater is when teams treat metrics like ends, instead of a means to an end. Trying to increase velocity unnecessarily or punish people for not having enough capacity turns these metrics inside out, leaving them empty of predictive power.

The pageantry here is all about numbers going up or down, checklists getting checked, and status bars creeping up. None of that, necessarily, means anything, no matter how much it feels like something. If you’re not careful, capacity and velocity can become vanity metrics, and their measurements can become meaningless to stakeholders.

The choice to measure is not neutral decision-making. Asking your team to measure something implies, at the least, that it’s worth measuring. Think through the consequences of what you’re asking them to measure and how you’re asking them to measure it.

Metrics are best when they measure something true and meaningful, not when they measure for the sake of measurement.

Strategic planning means taking the time to measure how effective these measurements are and how they’re making your team feel.

Just be careful not to get caught in an infinite measurement loop where you measure how effective measurements are, then measure how effective the measurements of those measurements are, and then measure how effective the measurements of those measurements of the original measurements are. Think about resource management. Nobody has enough resources or available capacity for that. Just checking your assumptions should suffice.

Velocity and capacity are tools, not hurdles

We’ve told you a lot about what to do and a lot about what not to do. This advice, however, is yours to adapt and use. If you take one thing from this article, the bottom line is this: the goal of capacity planning is to help.

An easy way to tell whether you’re using velocity or capacity wrong is to watch for when they feel like pain points. If it’s painful to use them, if it’s a chore to fill them out, then change how you use them.

The benefit of capacity planning is that it gives you the language to articulate what your team has done and can do in order to excel: your available resources, resource requirements, capacity requirements, resource utilization, current capacity, future capacity, excess capacity, workforce capacity, production capacity. They’re extremely useful in the right context and in the right mindset. But in the wrong hands, they can be confusing and annoying.

Shortcut is here to help. Get started with your free trial.