Planning with Velocity and Capacity
In a recent survey to a group of Scrum Masters, I asked a question about the definition of Velocity and I got a 50–50 split in the responses: “Velocity is a measure of work completed in prior sprints” and “Velocity is a measure of the value delivered in a sprint”.
Besides the lack of clarity on what Velocity is, what surprised me was that 50% of people chose an answer that has nothing to do with Velocity. Let’s clarify right away that Velocity has nothing to do with value delivered. In fact, it’s totally possible that a team has a high Velocity, is able to complete a ton of work each sprint, and yet is delivering little value to the stakeholders. Value is measured by the Product Owner, whereas Velocity is measured by the Developers on a Scrum team (maybe with help from the Scrum Master).
So, let’s clarify a few points in hopes of removing the confusion about how teams can use Velocity, and do proper planning for their sprints. To talk about Velocity we need to talk also about Capacity, because the two measures are interrelated.
Velocity and Capacity are two measures that Scrum teams can use for proper planning. They are used to estimate the amount of work in an upcoming sprint and make a reliable plan. Velocity is a historical measure of the amount of work completed in prior Sprints. Capacity is the measure of how much work the team can reasonably commit to completing in the upcoming Sprint, taking in consideration work estimates, average velocity, availability of team members, a buffer for unplanned work, and vacation days.
Here is real-life example of how using Velocity to estimate Capacity in a given Sprint can actually help the team improve performance: 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 used for planning of future sprints. Typically, you look at the amount of work completed in 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 upcoming 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” (AKA planning buffer)
Are you planning your work to fill you entire capacity? This may lead to overcommitment and missed release dates. In fact, planning work up to the entire capacity is usually a bad idea. It’s usually much better to choose a load that is less than the capacity, and leave a buffer that can be used for unexpected situations or unplanned work.
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 sprint backlog (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.
https://www.youtube.com/watch?v=pFkBQ8ojyE4
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. This is also called the Yesterday’s Weather pattern.
- 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 be conservative and able to adjust in light of unplanned work or unexpected events.
Example: Measure and adjust over time
Your team has already completed a number of sprints, and you are now planning 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
Max Capacity: 30 (assume no vacation/holidays)
Buffer: 6 points (for unplanned work)
Load: 24
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 buffer:
Team’s velocity (previous sprints): 32
Max Capacity: 32 (assume no vacation/holidays)
Buffer: 6 points (not planned)
Load: 26
In the middle of the X+1 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. You may have experienced a drop in velocity, but you were able to deliver 100% of your commitment for the sprint.
By using an interrupt buffer, your plans become more predictable. In this way, your stakeholders are happier, your release dates are more predictable, and everyone is happier.
Remember, velocity is not a measure of performance of a team. A higher velocity does not necessarily translate in a better team. In fact, velocity is just a planning mechanism to help predict the future sprint’s capacity more reliably. In the end, a team that is delivering 100% of its commitment on time is a much better team that another team who delivers a high velocity every sprint, but it’s not reliable and keeps missing deadlines.
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 team work at a sustainable pace, deliver on predictable commitments, and do work of the highest quality
Valerio Zanini is a Certified Scrum Trainer and can be found at https://www.trulyscrum.com/
