Scrum Velocity vs. Scrum Capacity: What Should You Choose?

Today, more and more companies adopt the Agile methodology for their product management.

However, shifting to Agile can be confusing for newcomers. That’s why people go with the most common frameworks. Scrum is one of them.

Scrum is indeed worthy of praise. It helps product teams increase their ROI, maximize productivity, and deliver excellent products.

But when you’re just starting, a few terminologies of Scrum may confuse you. In such cases, the Scrum Master’s responsibility is to familiarize their team.

Nonetheless, it always helps to know these terms as a product manager and team member. Today, we look at two such terms. They are ‘velocity‘ and ‘capacity.’

People working with Scrum for years still use the two terms interchangeably. Some may not know the difference. Others are just indifferent.

Now, ‘velocity’ and ‘capacity’ are not terms from the original Scrum framework. However, they are terms used by teams who adopt Scrum. Thus, it becomes crucial to know their meaning and difference.

First, let’s begin by briefly understanding what Scrum is.

What Is Scrum?

Scrum is an agile method that uses iterative and incremental procedures for software development.

Scrum is an agile framework that is designed to offer value to its customers throughout the product’s development. It is adaptable, rapid, flexible, and effective.

Scrum’s primary goal is to meet the needs of the customer by creating an environment of open communication, shared responsibility, and continuous improvement.

The development process begins with a broad understanding of what you need to develop. Then, following a list of characteristics ordered by priority (product backlog) that the product owner desires.

We carry out Scrum in short and periodic blocks called sprints, typically lasting two to four weeks. These are for feedback and reflection.

Each sprint is its entity, delivering a complete result, a variant of the end product. It must be supplied to the client with the least amount of work possible when required.

Now that you have a general idea about Scrum, let’s look at’ velocity’ and ‘capacity.’

What Is Velocity in Scrum?

First, let’s remember that the abovementioned term is not a Scrum practice. Product teams only use it for planning objectives.

Velocity refers to the number of story points a Scrum team can deliver in an iteration. It’s the rate at which developers can offer value per iteration.

Days, story points, ideal days, and hours are all ways to assess Scrum velocity.

The team has a set definition of what they want to meet by the sprint’s completion. The Scrum velocity of a team is 20 if it can deliver 20 story points in a Sprint.

In other words, Scrum Velocity is an approximation of how much the team has accomplished in the past.

When you use your past performance to plan your future sprints, you use the ‘velocity’ of the team.

Now we have a fair idea of what velocity means. Let’s look at how we can measure it.

How Do You Measure Velocity in Scrum?

Usually, we use the past three iterations to calculate the average team velocity.

So, we take the story points of the last three sprints the team has finished. Then you add them and divide them by three.

Thus, the average of these sprints gives you an estimate of the team’s basic velocity.

If you add more sprints, the calculation becomes more precise.

Once you have the story estimate, you can figure out how much you can do in the upcoming sprint. This will be acceptable and realistic for the team to achieve.

Unless there are exceptional and unavoidable situations, the estimated estimate can serve as a baseline for team members. You can set a reasonable goal during sprint planning.

Now, it could be your first time using Scrum. Suppose the team executes their first iteration and does not have previous data to determine velocity. In that case, they can follow the methods below.

1. Using industry-standard data.
2. Conducting a few initial iterations, and
3. Using expert hypothesis and judgment to deduce

The primary approach for determining a general scrum velocity for your first-ever iteration is to assess baseline velocity based on your preferences.

When you calculate ideal programmer time, you must factor in time spent on emails, discussions, design, documentation, revision, teamwork, and research. Similarly, you’ll need to factor sufficient time to account for project overhead and estimation errors if you’re using actual time.

If you underestimate the velocity with your first iteration, you add more features in the next one. But if you overvalue, you eliminate a few features.

Well, that will get you started! Velocity-based planning has quite some benefits. Here’s why you should spend time mastering it.

Why Should You Plan Based on Velocity?

• The size of a user story is a combination of risk and effort. Velocity strategy accounts for risk while planning.

• The specific lengths of the stories bring value to the release planning process by identifying assumptions, dependencies, and their influence.

• The team can discover areas where they’re wasting time and eliminate them to boost pace. Product managers can accomplish this through the collaboration of team members and stakeholders.

• Velocity planning takes into account each team’s strength. This gives rise to team alignment.

• It motivates the team to fulfill their obligations and provides them with a sense of accomplishment. It also enables them to improve their performance. Thus, their scrum velocity in future sprints eventually increases.

Well, now you know why velocity planning helps. It may not be a scrum practice, but these reasons justify its popularity.

As we talked, the more you engage in velocity planning, your team’s velocity gradually increases.

But, this isn’t a guarantee. There are certain factors to consider if you want your velocity to improve.

How Can You Improve Scrum Velocity?

Eliminate Unused Codes

The most important aspect is the ‘code.’ Product teams often overlook this. You need to ensure quality coding, and for this, the team must constantly factor in the code.

You should eliminate any code that is not in use. This will set you free from technical debt.

Unnecessary Testing

Don’t waste time on tests that aren’t needed.

This includes testing unused features, test overlap, or pushing a usual old code.

Unnecessary Planning

Plan for the short future rather than the long term.

Too much planning in advance and detail yields no benefits. It merely wastes time that could be better spent developing valuable features.

Sprint Retrospective

Try not to skip the sprint retrospective sessions. They help identify problems during the sprints and assist the team in resolving the issue.

This makes the next sprint simpler and easier to achieve.

And that was all about velocity in Scrum! Let’s now understand how it differs from capacity.

What Is Capacity in Scrum?

Capacity refers to the total time the team is available for work during a sprint. We usually measure it in hours.

Using this method, the team members choose the highest priority User Story and break it into smaller tasks.

Each task estimates how many hours it will take to complete in the Scrum capacity. If there is any capacity left, you select the next priority and add it to the sprint.

You have to choose the task so that the Scrum capacity is fully utilized and no additional capacity is available.

Now, let’s look at how we calculate this capacity.

How Do You Measure Capacity in Scrum?

In Scrum, we measure capacity using the following steps-

1. Calculate the maximum total available hours of all team members for a two-week sprint period.
2. Then, calculate the capacity loss. Subtract this from the maximum capacity. Let’s call this the adjusted capacity.
3. Now, get the ratio of your adjusted capacity to your maximum capacity.
4. And finally, you multiply his with your average velocity.

Let’s take an example.

Suppose you have ten members in your team for the two-week sprint. Each member works 50 hours a week.

Thus, the team’s maximum capacity would be 10 * 2 * 50 = 1000 hours.

However, 2 team members will be taking a leave for one week. That would make your capacity loss 50 * 2 = 100 hours. So, your adjusted capacity is 1000 minus 100 = 900 hours.

Now, the ratio of your adjusted capacity to maximum capacity = 900:1000, which is 0.9

Apply this figure to a hypothetical velocity of, say, 30 sprints. We get the capacity as 0.9 * 30 = 27.

That was a fairly elaborate example. You certainly understood how to calculate scrum capacity and how it differs from velocity.

Let’s look at the benefits of capacity planning.

Why Should You Plan Based on Capacity?

There are three significant reasons why capacity-based planning helps-

• The team’s capacity changes depending on the availability of team members at any given time. It assumes vacations, holidays, and other obligations, and each sprint is not treated the same.

• It takes into account the team’s available hours and does not solely rely on the story points. As a result, improved product release planning and a correct release date might be accomplished.

• Using User Stories in Sprint Planning allows the Product Owner and Developers to dig deeper into each story and establish a shared knowledge of the final product.

Just like velocity, it helps to have a higher capacity. However, capacity-based planning also has certain drawbacks.

These are as follows-

• This technique presumes that all task estimations are accurate because it commits the sprint size based on available capacity.

• It also presupposes that you can complete tasks simultaneously, which is impossible unless they are self-contained.

• It treats every team member equally, which is unlikely to be the case. Each person has a different ability, and they would do the assignment according to it.

• Employ user story sizing sparingly, as too much of it makes the work of sizing the user story meaningless to the team.

Now you know thoroughly about velocity and capacity in Scrum. The question that arises is- which one should you use?

Scrum Velocity vs. Scrum Capacity: Which One Should You Use?

You shouldn’t take this decision lightly. It will have a significant impact on your scrum team’s workflow.

Metrics aid in the team’s workflow and allow them to assess their ups and downs. It also demonstrates what your team will be considering during the development phase.

If you get your team too attached to the stats and metrics, they’ll fight you, and their morale will suffer. Teams with low confidence are less happy and productive.

You should employ Scrum capacity or velocity while considering the advantages and disadvantages of each planning strategy. If the advantages outweigh the disadvantages, then this is the planning strategy for your team.

It would help if you used these indicators to forecast the future and evaluate what has already occurred.

Regardless of which measures you employ, the central focus should be on:

• Delivering value and not completing goals.
• Making real progress and not ticking off your checklist.
• Making incremental gains and not creating a feature factory.

You should never tie time or performance because they are only used to ‘plan’ the next sprint.

We use them to make accurate estimates so that the right jobs can be chosen and executed.

If you hook these measures to exact hours, such as offering an engineer-specific hour and no more, you can’t expect the engineer to give it their all.

In the worst-case situation, if you are dissatisfied with the engineer’s performance, you may encourage them to make some alterations to their abilities.

In Conclusion

This article looked at the difference between Scrum velocity and Scrum capacity.

Scrum velocity is the rate at which a team can complete work in a sprint, while Scrum capacity is the maximum amount of work a team can achieve.

To get the most out of your Scrum implementation, you need to understand the difference between these two metrics and the target capacity to achieve the desired velocity.

Get started with the #1 Agile product management software to make your process effortless.