Differences between velocity and capacity planning
Over the years I have participated in many debates about how Sprint Planning should be done. Some say the best way is to rely on the team’s velocity. Others say no-no we should do capacity planning to be more accurate and do the right planning. So what is the right way of doing sprint planning?
In this article, we will look at the differences in velocity and capacity planning, will also discuss which type suits different teams. In another article, I’m going to describe the approach I prefer to use for planning. Also will provide a tool (excel spreadsheet) for running the best planning meeting.
First of all, let’s discuss a bit what are the velocity and capacity.
- Velocity is the empirical observation of completed story points in previous sprints and is typically measured as an average of actual story points completed across previous N sprints (I usually suggest the last 3-4 sprints for reference).
- Capacity is based on the team’s projected future availability, usually measured in hours. This may vary based on team members’ availability during the sprint.
Let’s dive into how we do the velocity and capacity plannings.
Here are the steps teams usually perform for velocity-based planning:
- Calculate average velocity (best for previous 3–4 sprints)
- Select stories from product backlog whose total sum of story points is equal or near to that average velocity
One of the drawbacks of velocity planning is that it doesn’t consider team members’ availability but that also can be solved by projecting team members’ availability to the velocity. For example, consider if the team has 5 members and the average velocity is 36, now consider if one of the team members will be on vacation during the full sprint, in that case, we can calculate the current sprints projected velocity to be equal to 36*4/5 = ~29 story points.
Another drawback or the limitation of the velocity planning shows up when the team has different roles, such as QA, Front-End, Back-End developers. In this case, when you take stories from backlog only based on their story points you cannot correctly estimate if some of the roles will be overloaded with work and others will not have enough load. For example, imagine the team took 3 stories and all include very heavy testing but the team has only 1 QA engineer. You might say that story points should already include QA’s work in them. Yes, but that doesn’t solve the problem as developers will complete the work and the QA person will have to work hard to support everything. You may now argue that the developers should jump and support with testing. Yes, of course, that would be the case for the high-performing teams, but what if we have the reverse situation when QA doesn’t have enough load based on the selected stories? Usually, QA cannot jump and support the development work. And the problem is that usually, such cases become visible only after the sprint already started, and during the middle of the sprint team realizes that someone doesn’t have work to do.
Probably this is one of the reasons that the State of DevOps report shows that eliminate hand-overs inside the team helps to improve the team’s performance. For our example, it basically means that if you don’t have a QA in the team your team will have higher performance.
Velocity planning usually works very well for experienced teams whose members didn’t change for quite some time and they have a good feeling of what they can achieve during the sprint. And usually, it doesn’t work well for newly forming teams, whose members change often, or the type of work is also changing and the team needs to do learning to do the work.
Here are the steps performed for the capacity planning:
- The team calculates the total available hours per role. For example, if the team does a 2-week sprint, has 5 engineers and one QA, then the total available hours for developers will be: 10 (working days) x 8 (work hours in a day) x 5 = 400 hours and correspondingly 80 hours for QA.
- Apply focus factor to the total available hours. That’s clear that nobody can be productive for all 8 hours in the day, we all have meetings, emails to read, and many other distractions that don’t allow us to concentrate on the work for the full 8 hours. That’s why usually we apply a focus factor, say ~80%, which means we will have productive ~6 hours in a workday. And hence hour total available capacity in hours will be equal to 300 developer hours and 64 QA hours.
- Take a story from the product backlog, breakdown to subtasks, and give an hourly estimate to every task
- Roll-up and sum estimated hours of all subtasks for every role in the team and compare with the role’s capacity to make a judgment if the team has taken enough work for the sprint.
So capacity planning helps the team to be more accurate in defining how much work they take for the sprint and also be able to see clearly if there are roles that are overloaded or roles that don’t have enough work. It allows teams to do the right discussions like, developers taking more QA work or bringing in another story which will utilize the team resources better.
The drawback of capacity planning is that it requires a lot of calculation and tracking during the planning and without the right tooling, it will be really challenging to accomplish the right capacity planning with less overhead.
Capacity planning works best for the newly forming teams whose team members change often or for the teams whose product backlog has work that team is not familiar with. Usually experienced teams automatically skip capacity planning when the same team members work on the same project for a long time, such teams usually pay much more attention to their gut feeling to understand how much work they should take.
The velocity planning is when the team relies on their historical velocity to define how much work they should take in the current sprint. Capacity planning is when the team projects the future availability of the team members, estimates tasks, and takes the corresponding amount of work.
Velocity planning usually works very well for experienced teams whose members didn’t change for quite some time and they have a good feeling of what they can achieve during the sprint. Capacity planning works best for the newly forming teams whose team members change often or for the teams whose product backlog has work that team is not familiar with.
In my next article, I will describe a planning approach that combines both these approaches and for me is the best way of running the planning meeting. It is an approach had proven its success in my own teams over many years. I’m also going to share the tool (excel template) I have developed that allows running the planning meeting in an organized way.