Capacity planning strategies for software development teams

In the day-to-day, it’s easy to focus on short-term plans for your development team. But the short-term is very much affected by long-term planning, specifically, capacity planning.

Almost every industry uses capacity planning. It generally falls into three categories: Strategic, tactical, and operational. For software development leaders, tactical capacity planning supports project progress. Whether you’re a scrum master, product owner, development team member, or even an IT executive, it’s crucial to understand the various approaches to tactical capacity planning. This understanding will help you meet current customer demand and fulfill future needs.

In this article we’ll introduce capacity planning and cover four common approaches to tactical capacity planning.

Capacity planning

‍Capacity planning is the process of analyzing all relevant variables to deliver a schedule of work that fits the size of its container – the team. Under the umbrella of operations management, capacity planning looks at the available infrastructure, time, and skills available to meet demand for product building, improvement, and maintenance. 

To borrow from economics, your goal is to find equilibrium – where the supply of labor meets the demand for product fixes – with an eye toward future demands to help maintain that balance. 

Part of building an ideal labor supply involves creating a capacity model that estimates how much labor you’ll need to meet future user needs. Tools to calculate the full-time equivalent (FTE), including Clockwise, help build this capacity model. Demand forecasting exists alongside capacity planning. Taking the plans for new products, updates, and similar, management can use tools to help paint a picture of where demand may go.

Unlike manufacturing, software development deals in knowledge rather than a supply chain of goods. In manufacturing, 10 pallets of metal frames take up 2,000 square feet requiring 5,000 hours of labor to turn each into a fully-formed bicycle. In software development, variables and inputs can be much more malleable. You can’t say, for instance, that there will be one bug fix per week within a given time frame. Bugs come up regularly, but often without warning. Product leaders have to plan to confront unexpected needs in the product development, implementation, and maintenance phases. 

Putting effort into forecasting capacity up front helps prevent future failures. For development and IT, failures may look like server outages, higher-than-average bug reports, and delays in sprint schedules.

Consider capacity planning for an e-commerce website with two well-publicized launches per month. Equilibrium in website demand and website infrastructure is met 99% of the time. On the two launch days, however, demand skyrockets risking overload and an inoperable website. Incorporating the user behavior from launch days into capacity planning means that short-term and long-term solutions are put in place. The website infrastructure expands. Team members dedicate larger time boxes on launch days to meet any challenges that arise. By accounting for changes based on witnessed patterns, the web team can spend more time improving and less conducting fire drills.

Who does capacity planning?

Within an organization, each team is responsible for tactical capacity planning based on the projects within their scope of work. Within the scrum framework, capacity planning involves the scrum master, product owner, and the development team. Each stakeholder provides input to determine what can be done and when. This process can happen within the context of a sprint backlog meeting. In this meeting, the product owner brings forward issues and tasks to be covered in the next sprint, listed in priority order. 

Capacity planning strategies

With the team and leaders gathered, there are a few ways to approach capacity planning. Some strategies focus more on calculated demand to determine allocation of resources to boost capacity while others look closer at current capacity and how much room there is for demand to expand. The scrum master and product owner can determine which strategy to follow, while input from IT executives can help in the decision-making process.

Using the helpful breakdown Marketing91 provides as a guide, here are four strategies to approach capacity planning – applied directly to software development.

1. Lead Strategy

When a team relies on this aggressive strategy, they’re looking at bulking up their resources – team members, skillsets, and more – to meet anticipated demand. For example, a team may be working on a feature, such as a new integration. Ideally, this new integration will increase app usage as users access its functionality in other apps they use regularly. 

Rather than wait to see how many new users these improvements garner, leaders (IT execs, scrum master, product owner) analyze and project the increased use before adding the resources to meet those projections. 

2. Lag Strategy

When additional resources are scarce ahead of a major app improvement, a team may follow the lag strategy. The team only adds capacity after current capacity is maxed out. This means the team meets future demand when it arrives. An ideal scenario might front load capacity; this strategy can still be effective as long as the team is prepared to make the adjustments necessary to meet a change in demand. It greatly reduces waste, but you also run the risk of losing customers due to disruptions in service.

3. Match Strategy

This strategy combines the best parts of lead and lag to incrementally build to meet demand. This is where the leaders plan to increase capacity before releasing a new feature or enhancement. But, unlike lead strategy, they don’t actually deploy the plan to increase capacity until they need the extra help.  

When demand decreases, capacity adjusts to match. Focus may shift to a different project or to preparing for the next sprint. 

4. Adjustment Strategy

Similar to lag strategy, the adjustment strategy looks to modify output based on changes in demand. The main difference is when changes occur. There is no capacity threshold – like reaching max capacity under lag strategy – guiding system or process changes. Modifications are a direct reaction to changes in demand. When using this strategy, you’re looking at modifying output based on these demand changes as they happen through adjustments big and small. You start with the available capacity of the team before reassigning focus based on the present needs. For example, a new trend emerges from user feedback pinpointing a fix in a product. Based on availability, the time of a certain number of team members is reallocated to address the feedback. 

These strategies encompass both low- and high-level planning. An executive may look at the entire organization as one unit when determining growth goals and the returns on output from that growth to be shared with investors or shareholders. On a department level, leaders look collectively at the teams’ output in the context of a capacity planning strategy. On the team level, leaders like the scrum owner and project manager consider the overall capacity of the individuals working to bring products, fixes, and improvements to life to support the overall mission of the organization. Capacity planning at this level depends on expectations from executive-level leaders while taking into account the skills and knowledge of the team. 

Team capacity planning

The first step in team capacity planning is to determine the variables involved. Start by assessing the capacity of the team based on individual feedback. Was there a need for certain skills that went unmet? What was the output based on the input of team hours as determined by absences? What part of the new product did team members spend the most time on? How much downtime occurred due to technical issues? Asking these questions can help the scrum master and product manager determine bottlenecks to overcome while understanding current capacity. Understanding these constraints also helps to determine the effective capacity – or the maximum amount of output for a set time period based on impacting variables.

Each person is themselves a variable. Individual work capacity based on hours available, out-of-office time, and depending on the organization, time spent helping other teams all contribute to the capacity of the overall team. 

Aside from schedules, another variable to contend with is budget. A product owner may have a long list of improvements – all of which could help improve user experience, retention, and sales – but resources are finite. It’s not always feasible to hire additional developers simply to complete a list, but ahead of a large product launch, IT executives may authorize more resources – impacting the capacity plan.

The next step is to list out the product or products your team owns. Based on previous sprints, analyze where the time and skills of your team gravitate toward. Understanding the categorical breakdown of time spent helps reveal where adjustments could provide more capacity. For example, if time spent on overall product improvements takes up a significant amount of capacity while building a new product takes less, the team can calculate the number of improvements or new products per hour. These figures then inform the capacity plan and allow for adjustments to boost capacity for different categories of tasks – automating one type of improvement to free up time for new product building.

Next, the scrum master and product owner should ask themselves “Can we dial back time spent on certain tasks without sacrificing progress?” Determining where there is too much focus can free up time – and thus capacity – to redistribute to other tasks or even take on new items. Alternatively, it’s important to address any bottlenecks that might show up.

Then, the scrum master, product owner and optionally, IT executives, can determine when next to hold a capacity planning session. The project pipeline and release dates for various products determine this date. A planned product launch could absorb 75% of a team’s time, but once launched, fixes and maintenance for the product likely falls, opening the capacity for the team to take on more. 

You may run one, two, or three sprints before a plan needs adjustment, but plan for updates accordingly. As mentioned earlier, there is always a chance plans will change – even on a weekly basis. Without a set amount of inputs, development teams need to be prepared to shift. 

Going forward

Capacity planning gives teams the aerial view needed to see what they can accomplish in a set period of time. The planning process encompasses input from leaders as well as individual team members to determine what the next few months look like before starting the process over. Finding the best optimization of the resources available is a practice rather than a perfect art. While there may be unexpected impacts that interrupt predetermined capacity plans, the time taken to forecast feasible accomplishments is never wasted. Scrum masters, product owners, IT executives and members of development teams all benefit when a long-term plan is established to guide overall growth for an organization.