Velocity, capacity, or load?

In this article we are going to discuss what is the velocity of an Agile team, how to calculate capacity for a Sprint, and then how to determine the load. But let me start with a true story:

We were half-way in Sprint Planning and suddenly it hit me. Like a light bulb turning on. I had been listening to the discussion between the Developers and the Product Owner and all seemed normal… until this very moment. I just realized that the team was planning their sprint with absolute no idea of velocity or capacity.

How did I figured it out? The Product Owner asked the team do do “60 points” of work and the team said “OK”. Not “let’s see”, “we’ll do our best”, or “let’s check our capacity and confirm what we can do”. Just “OK”.

Team discussing on whiteboard during meeting at office

I invited the team to open their burndown chart for previous sprints, and there it was. The team’s velocity was hovering around 28 points per sprint, and yet they were “OK” with taking on 60 points…. something was amiss.

This team was no different from many others with whom I’ve worked in the past. Work is given to them top-down by the power-to-be: product owner, CEO, customer… And the team just takes it on, struggles to do everything, works overtime, and maybe cuts corner on quality to complete the work on time by the end of the sprint.

In the process, the team members grow discontent, frustration, and lack of connection with the work they are doing. The more it goes on, the more this seems the normal way of doing. But there is a better way.

When we planned the next sprint using historical velocity as a measure of capacity, the team was able to increase their performance by 6 points (a 20% increase) going up to 34 points the next sprint. And two sprints later they were able to gain another 20% in performance going up to 40 points. Why?

Because they were able to focus on the work, minimize multitasking, and own the work they selected. These all drove performance increases. Teams that use velocity as a measure of capacity, and introduce a buffer for their work, increase performance.

So, let’s look at how you can do the same with your team.

Velocity, capacity, load

Teams that measure velocity (the amount of work completed in previous sprints) can use it as their upper limit to plan the next sprint. Why take more work than what we have been able to do in the past anyway?

The team can quickly establish capacity by starting from velocity and then adjusting it based on everyone’s availability during the next sprint. Based on capacity, the team can then decide their load, how much work they want to take on during the sprint. 

The load should be less or equal to capacity. Think of capacity as the size of a jar of cookies, and the load as the amount of cookies in the jar. Since you love cookies, I bet you’d like to fill the jar to the brim. However, there is nothing wrong with leaving some empty space in the jar. You can always add more cookies later if needed.

Are you planning to capacity? There are many reasons why you may want to choose a load that is lower than the available capacity. That’s called a buffer and it’s a good thing to have.

How to be effective at planning to capacity?

  1. Measure your velocity in past sprints, then calculate your average velocity – a good window is between the last 3 to 10 sprints. This is your team’s average velocity.
  2. Calculate capacity for the next sprint. Your starting point should be your team’s average velocity. Capacity may be lower if there are holidays or planned vacations during the sprint — decrease capacity accordingly.
  3. Decide how much work you want to take in the sprint. This is going to be your load. You may decide not to fill up your entire capacity, and instead leave some slack.

The power of slack

When a system, a machine, or a human being runs at its 100% capacity, we maximize utilization but we incur many other problems. For instance, if something unexpected shows up (there is a defect in a part that needs to be remade, or your babysitter calls because your kid is sick), you may not have spare capacity to deal with the unexpected event and complete your work. Something needs to give.

Also, if someone needs your help and you are utilized at 100% of your capacity, you won’t be able to help, therefore impacting someone else’s effectiveness. You may be able to deliver your work, but someone else on the team may fall behind. As a result, the whole team is affected.

Conversely, building a little bit of slack in the “system” creates the flexibility needed to deal with the unexpected, help other people in need, and be able to complete all the work promised with full quality.

Therefore, teams should select their load so that they leave a buffer to deal with the unexpected. Slack is a good thing and it’s the cushion that helps the team deliver on the goal – despite unexpected events.

For those of you that like math, here are the formulas:

load <= capacity <= velocity

slack = capacity – load

The difference between capacity and load is your planning buffer, also called slack.

Measure over time

Let’s say that you are in sprint X. Your average velocity in previous sprints was 30 points. When planning sprint X, you use velocity to calculate capacity, and decide to save 5 points as your buffer:

  • Team’s velocity (X-1): 30
  • Capacity (X): 30 (assume no vacation/holidays)
  • Load (X): 25
  • Buffer: 5 points (not planned)

Fast-forward to the end of the sprint and you completed all 25 points of work plus an extra 5 points: in fact, you finished the 25 points early, nothing unexpected happened, and you pulled more work from the backlog to fill the buffer. And so your actual velocity for sprint X was 30 points.

Now you can use that information to plan the next sprint X+1. You could decide again to save 5 points for “slack”:

  • Team’s velocity (X): 30
  • Capacity (X+1): 30 (assume no vacation/holidays)
  • Load (X+1): 25
  • Buffer: 5 points (not planned)

In the middle of the sprint you discover that one of the work items is bigger than expected and an unexpected event pulls you out of work for a while. If you had no buffer, you would not be able to complete the work on time. But since you had created a buffer, it gives you the flexibility to deal with the unexpected and still complete the work. So at the end of sprint X+1, you complete everything you committed to doing (25 points), delivering on your goal thanks to the buffer you created (slack).

Looking back at the amount of work completed in each sprint, your velocity for sprint X was 30, and for sprint X+1 was 25. Now you need to plan for sprint X+2 and you can start with a capacity of 25 points based on your last sprint’s velocity.

Or, you can calculate your team’s velocity as an average of the last 3-5 sprints and offset the impact of sporadic events to use a more predictable velocity. The goal is to help the teams work at a sustainable pace, deliver on predictable commitments, and do work of the highest quality.

Velocity, capacity, or load?