In this article I am 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”.
I invited the team to open their burndown chart for previous sprints, and there it was. The team’s velocity was hovering around 27 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 33 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
Velocity is the amount of work completed in previous sprints. It’s a measure of past performance for the team. Typically, you look at the last three to five sprints, and take the average of their velocity. This helps to offset any spikes in a particular sprint. Teams that measure velocity can use it as their upper limit capacity to plan the next sprint. This is the Yesterday’s Weather pattern in action: we look back at past performance in previous sprints, and we use that measure to establish a baseline for capacity in the upcoming sprint.
Capacity is the maximum amount of work that the team can commit to doing in the next sprint. The team can quickly establish capacity by starting from the average velocity and then adjusting it based on everyone’s availability during the next sprint. For example, if you know that a couple of team members will be in vacation during the sprint, you need to reduce your capacity by a proportional amount. Capacity should always be equal to or lower than the average velocity of the team, to avoid overcommitment.
Load is the amount of work selected by the team for the current sprint. This is the amount of work that the team is planning to complete in the sprint. It should be less or equal to capacity (otherwise the team is overcommitting). You start from your capacity, and then decide how much work you want to actually select for the sprint.
The load should be less or equal to capacity. Think of capacity as the maximum quantity of a jar of cookies, and the load as the amount of cookies actually 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.
The power of slack (planning buffer)
Are you planning to capacity? There are many reasons why you may want to choose a load that is lower than the available capacity. The difference is called a buffer and it’s a good thing to have.
When a system, a machine, or a person 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 work, help other people in need, or be able to complete all the work promised with full quality.
This is what we call a planning buffer: it is a portion of your capacity that you don’t use for the plan, but instead leave it aside for unexpected work that may show up for you during the sprint. This is called the Interrupt Buffer and it’s a good practice for a Scrum Team to always leave a portion of capacity unplanned. A good starting point for the buffer is 10% to 20% of your capacity. Some teams may need a bigger buffer if they deal with a lot of responsive work (e.g. emergency work in production).
Therefore, teams should select their load so that they leave a buffer to deal with the unexpected work. Leaving a bit of slack in your plan 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:
velocity >= capacity >= load
buffer = capacity – load
The difference between capacity and load is your planning buffer.
How to be effective at planning to capacity?
- Measure your velocity in past sprints, then calculate your average velocity – a good window is between the last 3 to 5 sprints. This is your team’s average velocity.
- 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.
- Define your buffer. Leaving a portion of your capacity unplanned helps to prepare a more realistic plan. 10% to 20% of capacity is a good starting buffer.
- 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 a buffer.
Example: Measure and adjust 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 6 points as your buffer (20% buffer):
- Team’s velocity (previous sprints): 30
- Capacity: 30 (assume no vacation/holidays)
- Load: 24
- Buffer: 6 points (not planned)
Fast-forward to the end of the sprint and you completed all 24 points of work plus an extra 10 points: in fact, you finished the 24 points early, nothing unexpected happened, and you pulled more work from the backlog to fill the buffer (an extra 10 points of work). And so your actual velocity for sprint X was 34 points. Let’s assume that your average velocity then increases to 32 points.
Now you can use that information to plan the next sprint X+1. You could decide again to save 6 points for “slack”:
- Team’s velocity (previous sprints): 32
- Capacity: 32 (assume no vacation/holidays)
- Load: 26
- Buffer: 6 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 (26 points), delivering on your goal thanks to the buffer you created. Your velocity for sprint X+1 was 26. This may drop your average velocity a bit (say, down to 28 points considering the last 3 sprints).
By calculating your team’s velocity as an average of the last 3-5 sprints, you can offset the impact of sporadic events and have 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.
