Step 2 - Estimate Capacity
You’ve collected the work – now ask: how much can we really do?
Once you have full visibility into the work, the next step is to assess your team’s capacity to deliver it. In the post called “Understand your Capacity to Deliver,” we talked about the reasons why it is so important. In this post, we’ll lay out some practical guidelines for estimating capacity and building trust in what your team can deliver.
What You’re Aiming For
You want to estimate the effort required (in person-weeks or an equivalent unit) for each item in your PoR. Then, you compare the total effort to the actual capacity of the teams.
At a startup, this is relatively simple. You can probably fit the entire development team into one room, and communications are fast and informal.
But if you’re operating at any real scale, it gets more complicated:
You likely have multiple product lines
You’re managing multiple cross-functional teams
Some engineers are interchangeable across teams, while others have specialized skills
DevOps, infrastructure, and infosec are shared services with limited capacity
Your PoR must account for all of this complexity — and still be usable.
Two Capacity Challenges
You’ll need to overcome two big challenges:
Gaining trust from the executive team that your capacity estimates are reliable
Building the skills within product and engineering leadership to estimate capacity well
Both take time. But you can start by tackling the easier parts first.
Start with Recurring Work
Recurring work categories — like outages, bug fixing, DevOps, infrastructure, and security — are a good starting point for estimates. For recurring work, you don’t want to prioritize individual tickets but you need to estimate and reserve enough team bandwidth to handle the work. If you have decent historical data, your estimates will be fairly reliable.
Of course, many teams don’t have great data to begin with. That’s okay. Make your best estimates and iterate. Over time, track estimated vs. actual to refine the model and build trust.
Also: don’t forget to factor in time for meetings, 1:1s, performance reviews, and unexpected strategic work like M&A due diligence. This kind of overhead is real and needs to be visible.
Estimating Roadmap Work
The harder part is estimating capacity for non-recurring work — especially new features and product improvements.
This depends heavily on:
The quality of your product requirements
The level of engineering experience
The presence of external dependencies (design, data science, research, DevOps, etc.)
This is where your team structure matters. If your teams aren’t cross-functional or don’t have stable ownership of products or features, your estimates will be less accurate — and your ability to deliver will suffer.
You’ll also likely uncover resource contention problems. For example, several teams may depend on the same data science resource or infosec expert. These contentions must be surfaced and planned for in your PoR.
And here’s where trust-based culture comes into play again: if engineers don’t feel safe raising concerns or exposing risks, your estimates won’t be honest — and your roadmap will be fantasy.
What If the Estimates Aren’t Great?
They probably won’t be — at least not at first.
So start with what you have, declare your intent to improve, and create transparency about how you’re measuring actual vs. estimated. This builds trust and improves accuracy over time.
And don’t make the mistake of trying to sandbag. If you’re always hitting your targets, your executive team will start to assume you’re padding the numbers. That undermines trust too.
The goal isn’t perfection. The goal is to build a habit of informed estimation, transparent communication, and continuous learning.
Up next – With a clear view of the work and your capacity to deliver it, you’re finally ready for the core step: making prioritization decisions.