You’re looking for a guide to capacity planning, and we can understand why. When we surveyed hundreds of product professionals in organizations around the world for the Craft.io State of Product Management Report, respondents ranked capacity planning as the #1 challenge they’re facing today.
More specifically, Product Managers cited three primary difficulties that lead to frustration with the capacity planning process:
- Managing the workflow across different stakeholders.
- Collecting accurate effort estimates from development teams.
- Creating clear scenarios to visualize tradeoffs within a given quarter or release.
We would also add a fourth challenge to that list: the lack of a proper capacity planning tool. Constantly switching between apps to allocate limited resources creates friction and data silos. Understanding the benefit of capacity planning is essential to overcoming these hurdles, as it allows for realistic expectations and data-driven decision making.
This guide provides a proven walkthrough of the steps involved, how to collaborate with stakeholders, and the capacity planning software features you need to succeed.
First, though, let’s make sure we’re on the same page about what the process is and why it’s so important for product organizations.
Defining Your Capacity Planning Framework
Capacity planning is the process of determining the needs of your planned work and then making sure your company will have sufficient resources to meet those needs when the time comes to execute. Or, as we described it in our blog, 7 essentials to simplify capacity planning, it’s a process to help a company allocate its resources to maximum effect.
To visualize this for your next project, consider these granular requirements:
- Resource Alignment: If you prioritize ten epics for a quarter, you must verify if the development team possesses the specific skill sets required for those tasks.
- Granular Scheduling: When moving into a sprint, you must confirm that the team has enough available hours within that two week window to finish the specific items you have proposed.
- Skill Distribution: Capacity is not just about total hours; it is about whether the right people are available at the right time to prevent bottlenecks.
Essentially, this stage of the product planning process acts as a reality check for your roadmap. It moves you beyond a strategic wish list and into a feasible plan of action based on the actual bandwidth of your workforce.
What Is the Value of Capacity Planning?
Without an effective process for resource capacity planning, your team misses a vital piece of the prioritization puzzle.
Let’s say you prioritize a new feature for your company’s SaaS product based on strong research and strategically sound reasoning. For example, you’ve built a compelling, data-supported case that delivering this feature within a given timeframe will lead to more trial downloads or that it will reduce customer churn.
If you haven’t first determined that your development team can deliver this new functionality in the timeframe you’ve set, you could fall short of those legitimate business objectives. Even if you manage to pressure your dev team to step on the gas and prioritize your work over other projects already on their agenda — and even if they pull it off — that success could come at the expense of your company failing to complete other important product work on time.
In any organization, a key part of the product management role is making difficult decisions based on the company’s business objectives, product priorities, and limited resources. This is why knowing how to conduct effective capacity planning is vital to your success as a Product Manager.
Now let’s review a useful capacity planning framework.
A Proven Capacity Planning Framework
Step 1: Prioritize the work.
Some capacity planning strategies will tell you to estimate your capacity levels as the first step in your process. And although that approach can be effective, we’ve learned from working with many product teams that, in most cases, capacity planning is more effective when the team first determines the most strategically valuable or important projects to work on (independent of the company’s resource limitations).
Just as a successful Product Manager knows to start by looking for a market need — as opposed to thinking up features to build because they sound cool — you don’t want to start by estimating your development team’s capacity and then give them projects to fill that time.
Instead, you want to start by determining what your product organization needs over an upcoming timeline, such as the following quarter. Then, after you’ve determined what initiatives you want to prioritize — based on strategic planning and your business objectives — you can begin focusing on your capacity levels to find out which of those priority items will be feasible and which will need to wait.
Think of the first step as creating your product team’s strategic wish-list.
Note: Prioritizing initiatives using consistent scoring criteria is vital, because every piece of work needs to demonstrate a clear strategic value to your company before it earns a spot on the product roadmap or sprint.
That means you’ll want to use proven prioritization frameworks to determine which items deserve attention in which order, and the best way to do this is with a product management solution that has best-practice prioritization frameworks built in.
Step 2: Assess your capacity.
With your priority initiatives determined, it’s time to find out the level of resources you will have over the time period you’re hoping to complete those initiatives. We’ll assume you’re thinking about capacity and resources in terms of your development team’s work hours.
If you’re hoping to complete a handful of epics over the coming month, for example, you’ll need to determine:
How many hours each epic will likely take to complete.
How many hours your development teams have available in that timeframe.
Whether other projects will also be making claims on those developers’ time.
As we pointed out in our blog on simplifying capacity planning, you’ll also need to factor in issues such as employee turnover (will some developers leave the company during this timeframe?) as well as illnesses and vacation time (will we have periods when the company is down a developer or two due to leave?). When you factor in those variables, you might want to assume more total days or weeks to complete each epic on your priority list.
Note: Treat capacity planning as a cross-team activity.
You can conduct your capacity planning exercise in a vacuum — at least at first — where your product team makes its own estimates about the developers’ time to complete each epic. This can give you a useful first draft of your plans, particularly if you’re using a tool that lets you track and analyze your team’s work over time — for example, a product management solution that integrates with Jira and other workflow tools.
You can use such a tool to review your developers’ historical work on similar projects to get an idea of how long your new tasks should take them. Then, using those estimates along with the information you can find about your developers’ upcoming workloads, you can get a sense of how many days or weeks it might take your developers to complete them.
But you need to remember that at this stage, you’re working in a vacuum. Until you’ve synced up with your development team to get their input, you can’t be confident of your estimates. There could be variables you haven’t considered — for example, other projects that your development team has committed to but that you’re not aware of because they’re for other teams across the organization.
This is another reason you want to use a product management solution that gives you not only a window into your own products’ status, progress, and dependencies but full visibility across your company’s entire product portfolio. You can’t gain the full picture of your development teams’ capacity levels until you have a companywide view of what they’re working on throughout the organization.
This is also why you should view capacity planning as a joint project between product and development. The more you treat your development team as a true partner, the more the team will respect you, appreciate your trust, and want to help make your products successful.
There’s also one more reason to collaborate closely with your development team on capacity planning. According to research published in ScienceDirect, businesses should view their capacity planning as dynamic systems. The paper focuses on machines being taxed beyond their limits — and the problems that result from this — but a similar phenomenon happens with people.
If Product Managers make assumptions about their developers’ abilities to complete specific projects, and they overestimate how quickly these developers can perform tasks or underestimate the levels of difficulty, the Product Managers are giving those developers incentive to push back on future projects with longer estimated time frames.
Bottom line: Treat your development team as the vital participants in the planning and resource allocation process that they are.
Step 3: Monitor your plans closely and adjust when needed.
This final step will be ongoing. You’ll start working on it almost immediately after you’ve kicked off your planned work with development.
That’s because capacity planning is always an estimate — never a guarantee. You and your development team will do your best to estimate timeframes for completing work given the information you have at the time. But those realities will inevitably change.
What Are the Types of Capacity Planning?
You also want to make sure you’re using a capacity planning strategy that’s appropriate to your product’s stage of growth, company culture, and other factors. Here are the three broad types of capacity planning.
Lead capacity planning.
This approach is used when you anticipate an increase in demand or resource needs over a specific timeframe. For example, a business entering a growth stage might hire additional developers and designers in anticipation of a need.
- Risk: You are adding costs before the increase in demand actually materializes, which can lead to overspending and idle resources.
Lag strategy planning.
This conservative approach involves planning only for projects already defined and agreed upon. You increase capacity only if you experience a need in real-time.
- Risk: This approach risks leaving your team with fewer resources than needed to meet immediate demand, which could hurt your reputation.
Match capacity planning.
Both the lead and lag approaches to capacity planning commit to large-scale and longer-term changes. Lead proactively increases resource levels ahead of time, while lag purposely limits them until the team is completely out of capacity.
The match approach represents the middle ground and is the right strategy for companies that take a shorter-term view or have shorter development cycles. With the match strategy, you’ll make smaller adjustments to your capacity levels along the way according to need.
What Does the Right Capacity Planning Tool Look Like?
As we noted in the introduction, capacity planning represents the most-cited top challenge for Product Managers today. We believe that challenge arises in many cases because the product team doesn’t have the right capacity planning tool.
Many Product Managers plan their capacity using spreadsheets. They track development teams’ times and other data in a spreadsheet and then regularly review the developers’ current and planned tasks and project status in Jira (or Azure DevOps or some other development workflow tool).
What Product Managers and their development team partners should be using instead is a comprehensive product management solution with built-in capacity planning.
Craft.io acts as a central hub that pulls together your strategic roadmap, prioritization frameworks, and developer status.
- Centralized Data: Access resource levels and project status in one place.
- Built-in Planning: Use a dedicated capacity planning tool to allocate resources efficiently.
Simulate Scenarios: Simulate how adjustments to resource levels or time frames would affect overall capacity without changing the live roadmap.
