In the previous article, we have talked about the Product Roadmap Planning process. As a result of this process, you are expected to get a product roadmap that includes a clear indication of the scope to be delivered and its timeline.
But how do you get there?
This question is being asked quite often. In this article, we're going to give you a complete picture of how to plan your teams' capacity and different capacity planning strategies so you can create accurate product roadmaps.
Let's start with the basics.
What is capacity planning?
In software development, capacity planning is defined as a process of assessing if the company can meet its product roadmap goals with the current staffing and identify gaps. Its objective is to set proper expectations with other cross-functional teams, so they can plan their activities accurately (e.g., marketing launches, sales activities, etc.).
How far along should you be planning your product roadmap?
Most established organizations typically need to have visibility into the 6-12 months ahead of them.
However, don't think that you need to have every single feature planned out for a year ahead of you.
Rather, you should treat your yearly product roadmap as a north star and be comfortable changing your mid- to-long-term roadmap as you get new insights about your customer, market, and industry needs, etc.
Teams over Individuals
Another critical aspect to highlight is that you should focus on team capacity rather than individual employees, especially if using Agile/Scrum methodology.
It's highly beneficial to the product success to have teams with all the skill sets needed to complete product roadmap items. It might mean that you need to have frontend, backend, quality assurance engineers all in one team to ensure that you deliver a working increment at the end of the iteration.
Prioritized Product Backlog
We've covered it at length in the Product Roadmap Planning article, but it's essential to ensure that you have a prioritized product backlog that everybody is aligned to at the beginning of this process. This will help with tradeoff conversations if some items aren't going to fit into the desired timeline.
Determine Your Planning Horizons
As mentioned before, most established organizations typically need to have a yearly roadmap, but depending on your company & industry needs, you should determine planning roadmap horizons that work best in your case. Most commonly, you will have your current quarter as planned roadmap (80-90% confidence in delivery), the next one as targeted (70% confidence), and the next six months after as directional (with 50% confidence).
However, more and more companies are trying to shorten their planning cycle and focus on the upcoming six weeks as a planned roadmap horizon. So pick what best for you depending on the specifics of your company and industry.
Okay. Now, we have established our baseline. Let's dive into the Capacity Planning Process itself.
Capacity Planning Process
To make this process more tangible, let's take a look at the specific capacity planning example.
Your company is developing a software product and has two full-stack teams that are experts in their domain areas (Team A, Team B). These teams have been with the company for quite some time and have predictable velocity, measured in Epic Points during high-level estimation, and they use story points during execution. The company is going through a quarterly roadmap planning process and hopes to deliver ten new product features at the end of the quarter. Product, Engineering, Design, and Project Managers collaborate to come up with the best plan of action.
Step 1: Understand Historical Velocity
If you've been working with the same teams for quite some time, take a look at their historical velocity. Regardless of the estimation units you use, whether it's story points, epic points, T-shirt sizes, ideal hours, etc., count how much each team completed within the same period previously.
If you haven't been tracking your historical velocity or starting with the new teams, just let teams pick their starting velocity as the best guess and go from there. You will be able to refine it moving forward.
In our example, it looks like this:
Step 2: Determine Available Capacity
Assuming that you have the same number of teams for the upcoming quarter, and you don't expect any changes to the team structure, your available capacity might be equal to your velocity from a previous quarter.
If you're expecting some changes, such as a team member leaving, or a new member joining, adjust it accordingly.
In our example, we aren't expecting any changes. So we will assume that our teams can complete the same amount of work as they did last quarter.
Step 3: Assign Teams
Okay, now we have a pretty good idea of how much capacity we have for the upcoming quarter. Let's start looking at team assignments.
Depending on your team structure, your teams might be available to work on any part of the product, or they are domain experts in specific areas. Whatever the case is for you, get your cross-functional team (product, engineering, project manager, and designer) in the same room and decide how you want to tackle your prioritized backlog, which teams are best positioned to solve these problems.
At this moment, your roadmap wasn't estimated as you would want the teams assigned for specific features to be providing estimates.
In our example, we have assigned teams based on their domain expertise.
Step 4: Estimate Work
Now, you have the work divided between the teams. The next step is to get a high-level estimate from teams. The best approach is to do a relative estimation by comparing new backlog items to previous similar work.
You can decide which estimation units you would like to use for the high-level estimation. The two most common are Epic Points and T-shirt sizes, but it's your decision what works best for your case (whether you estimate in hours, story points, or anything else).
In our example, we're going to use Epic Points with a scale of 10, 20, 30, 50, 80, 130, and so on.
Step 5: Check Teams' Workload
Based on high-level estimates received, you should get a clear picture of whether your teams can complete all work assigned and whether they are over- or under-loaded.
In our example, you can see that both of our teams are overloaded based on high-level estimates we've got from them and won't complete all the work that we would like to fit into the next quarter. So we should look into different scenarios and see if we can make any changes.
You can also quickly see that while our initial product backlog was estimated at 310 epic points, based on our team assignments, we've planned only 150 epic points out of 210 available. This means that we should explore different scenarios, and try to find a way to deliver more value in this upcoming quarter.
Step 6: Explore Scenarios
Depending on the result of high-level estimation, you might want to look at alternative scenarios by exploring changes in backlog priority, splitting large items into smaller, changing team assignments, and so on. The goal you are pursuing is finding the best plan of action to maximize the value delivered in the upcoming quarter.
Let's look at our example then.
The teams think that they can complete 6 out of 10 product backlog items. A few roadmap items are pretty big in size (features 7 & 8), and that's why they don't fit into the next quarter roadmap.
So we have a couple of options:
Leave our team's commitment the way they are, and let the teams start working on them, but don't expect them to finish it.
Change the priority of Feature 9 and 10, as they are smaller in size and can fit into the next quarter.
Split these large items into smaller chunks if possible (we will do it with feature 8)
We have explored two different scenarios, and it looks like scenario #2 delivers the most value, so that we will proceed with it. But keep in mind that it's still just high-level estimation, so you should expect to have 80-90% confidence.
Step 7: Execute!
Execute, and have fun!
Step 8: Analyze Your Learnings
All right! You are at the end of your planned quarter, so let's take a look at how accurate your planning was. And most importantly, what we can learn from it.
In our example, Team B has completed everything that they have planned.
And Team A has done most of the work but Feature 10. They have encountered that Feature 10 is more complex than they thought and requires more technical refactoring to be able to move fast in that area. You might want to add a technical debt epic to address this challenge later, by the way.
It's a great learning experience! So next time when they will be working in that area, the team would put a higher estimate there, making the high-level estimation process more predictable over time.
Both of our teams delivered 190 out of 210 committed epic points, which is amazing. Not only the teams have been able to deliver more value than our initial plan, but they also got valuable learnings that will help in the future.
Takeaway
Product Roadmap & Capacity Planning process is at the core of any software development company, and if done correctly, allows companies to get a realistic picture of what to expect at the end of the planning cycle and make changes proactively.
There are not that many tools that allow teams to explore different product roadmap scenarios and make informed decisions quickly. And while a lot of companies use Jira and other similar tools as their DevOps tool, they don't provide capacity planning out-of-the-box. So many people end up relying on manual spreadsheets to do capacity planning, which is very tedious, quickly becomes outdated, and not synchronized with the main development tool (Jira, Asana, Trello, etc).
OneRank, the Ultimate Product and Capacity Planning tool, was built to enable companies to plan their product roadmaps seamlessly, understand teams' historical velocity, explore alternative plans, and help discover the strategy that brings the most value to the customers and business. It empowers teams to explore these scenarios quickly, eliminating the majority of manual work and is tightly integrated with Jira.