Reviewed by: Madhur Kathuria
Capacity planning is used by scrum teams to help them estimate the amount of work they can accomplish in the current sprint. When they have a good idea of their capacity, they can make an informed decision about how to fill that capacity.
Successful capacity planning helps teams meet deadlines and complete the work they've estimated they can complete during a sprint. Planning for capacity prevents over-commitment, which leads to missed deadlines and interferes with the team's ability to focus during the sprint as they spread themselves thin on too many items.
Capacity is the maximum amount of work a team can complete in a given timeframe, and capacity planning is the process of defining that capacity and often includes deciding how much work to add to that capacity.
When a scrum team plans how much work they should forecast during sprint planning, they usually start by defining their current capacity, based on some or all of the following:
Actually, many types of work teams and project managers go through a similar process, not just scrum teams.
In any industry where a business promises delivery of product on a certain timeframe, they engage in some form of capacity planning.
For example, if a candlemaker gets an order for candles, they will look at the number of candles ordered and compare it to the number of candles they can produce using their equipment and labor to determine how long it will take to deliver the order. If the customer wants the candles sooner, the candlemaker might add an extra shift, buy additional equipment, or shift some ongoing production commitments around. They know they need to do this because they know their capacity.
Determining capacity during sprint planning is similar but with one essential difference. Instead of looking at the project as a whole, scrum teams plan capacity on the basis of short sprints, which can last from one to four weeks. In each of these sprints, scrum teams seek to deliver a certain chunk of value from what is described in scrum as the product backlog: the ordered list of work to be accomplished to develop the product successfully.
Most teams figure out the number of hours each team member has available to work over the course of the sprint to define capacity.
For example, let's say that your sprint is two weeks (10 days) long. That's 80 hours per employee. However, you should subtract the timeboxed events in your sprint. That might be four hours for sprint planning, two and a quarter hours for daily scrums, two hours for sprint review, and an hour and a half for sprint retrospective, a total of, let's say ten hours per employee (9.75, actually), leaving about 70 hours for each employee.
If there are any holidays during the sprint, make sure you subtract the appropriate amount of time (typically 7.75 hours) per employee from your capacity. Then subtract hours for each employee that has time off planned during the sprint. Finally, multiply the hours by what is often called a "utilization rate" or "focus factor," which accounts for the fact that no one spends 100% of working hours actually doing work.
You can either use a single focus factor for your team or allocate individual focus factors to team members. Common focus factors are 0.6-0.8.
How you proceed to fill the capacity depends on how you conduct your sprint planning. If you use a story point method, you could consider your team's average or recent velocity to determine how many points you want to commit to based on past performance.
Capacity will impact a team's velocity.
"Velocity" is the amount of work completed in a sprint. If your team assigns points to product backlog items, you'll use these points to measure velocity by totaling up the number of points completed in a sprint.
Teams may use average velocity as they talk about their capacity and how much work to bring into the sprint. Say in the last three sprints your team completed 80 points, 75 points, and 50 points respectively. That means the recent average velocity is 68 points.
If a team's capacity is lowered by, let's say—holiday vacation time, then they may not meet their average velocity this sprint. Since they know their capacity is lower than usual, they may decide to work on a lower number of story points than is typical for the team. It's up to the scrum team developers to decide what they want to work on in a sprint, and velocity is one of the factors they may use to inform their decision, along with their capacity.
Later, if the team is reviewing their own performance and noting dips in velocity, capacity may explain the dip partially or completely.
A common pitfall is for management to compare the velocity of different teams and try to adjust the capacity planning of teams that are "underperforming." Each team should strive to optimize their productivity, but leaders and managers should resist pressure to arbitrarily add capacity to a team or use capacity and velocity as ways to rank team performance. Instead, the scrum team should be empowered by leadership to use velocity and capacity measurements to self-organize around their sprint goals and sprint forecasts.
Some of the benefits of capacity planning include:
The outcome of sprint planning is a forecast of the value and backlog items a scrum team can deliver in the current sprint. Accurate capacity planning supports their ability to make an accurate forecast, in turn increasing the predictability of what they can achieve in a sprint.
Scrum teams consider this a forecast and not a commitment to getting a set amount of work done in the sprint. A "commitment" to complete a certain amount of work ignores the possibility of unforeseen circumstances requiring the team to change their sprint backlog.
A forecast, instead of a commitment, supports a scrum team's adaptability and ability to pivot in response to change.
Effective capacity planning means that your team will be able to deliver value early and often, getting closer and closer to the ultimate product goal. Even when capacity planning might force a revised timeline—because of an optimistic initial estimate or changes in the product specifications, for example—capacity planning lets you see this challenge early so you can either alter your capacity or notify stakeholders of a delay far in advance.
Good capacity planning ensures teams take on the amount of work they believe they can accomplish in a sprint. A team prevents burnout by forecasting reasonable sprint backlogs. Also, by taking on a chunk of the product backlog that they can actually complete, the team may end up consistently achieving sprint goal after sprint goal, which leads to a sense of success and satisfaction.
Overcommitting or maxing out capacity may cause the team to feel stretched thin, unfocused, and unable to complete all the work they had forecasted.
Capacity planning can improve morale organization-wide, with effects that reach beyond a single team. As success stories spread when teams reach their sprint goals and feel motivated by their sprint work, organizational morale has the potential to reach new heights.
In proper capacity planning, teams account for their scrum meetings, team member vacancies, team member vacations, missing resources, and other factors that will influence what and how much they can accomplish in a sprint. By factoring in sprint reviews, sprint retrospectives, and other collaborative interactions as needed, capacity planning puts intention on the team's ability to continuously improve and grow.
Properly executed, capacity planning can help your team achieve its sprint goals, improving their morale and the companywide morale. However, as with many aspects of agile development, capacity planning is a skill that can take time to develop. Fortunately, developing skills is one of the things that agile frameworks do best. After several sprints, your ability to do capacity planning will improve, and the benefits will increase.
If you want to learn more about how scrum's events, artifacts, and team accountabilities work together to help you deliver more value to customers, dive into the Scrum Essentials microcredential course. This focused course will guide you through the basics of the framework and provides a great jumping off point to upskill in agile practices.
Get the latest resources from Scrum Alliance delivered straight to your inbox
Subscribe