Every quarter, product leaders commit to roadmaps that assume 100% of their team's time is available for feature work. It never is. Between on-call rotations, support escalations, vacation, sick days, tech debt sprints, and the meeting tax on every engineer's calendar, actual available capacity is typically 55-70% of theoretical capacity.
This template builds a realistic capacity model that accounts for all the time sinks your team faces. It calculates available engineering days per sprint and per quarter, then helps you match that capacity to your planned initiatives. The result is a delivery plan that your team can actually hit, not one that requires heroics every week.
Quarterly planning. Before committing to the next quarter's roadmap.
Sprint kickoffs. To calibrate how many story points or tasks are realistic for the sprint.
Headcount justification. When building the case that your team is at capacity and needs more people.
Re-org or team restructuring. When team composition changes and you need to rebaseline.
Post-mortem on missed commitments. When you shipped less than planned and need to understand why.
Cross-team dependency planning. When another team needs to reserve capacity for your initiative.
How to Use This Template
Step 1: List Your Team
Enter every person on the team with their role, average hours per week, and any known constraints (part-time, shared with another team, ramping up).
Step 2: Calculate Gross Capacity
Multiply headcount by working days in the period. This is your theoretical maximum.
Step 3: Apply Deductions
Subtract planned time off, on-call rotations, support load, meetings, and any standing commitments. Use historical data from the last 2-3 quarters to estimate these if you don't have exact numbers.
Step 4: Set Allocation Targets
Decide what percentage of net capacity goes to new features, tech debt, and unplanned work. A common starting point is 70/20/10, but adjust based on your product metrics and technical health.
Step 5: Match Capacity to Initiatives
List your planned initiatives and their estimated effort. Compare total planned effort to available capacity. If planned work exceeds capacity, cut scope or push timelines before the quarter starts.
Note: Sam counted at 0.6 FTE (effective) due to 5 weeks of ramp-up in a 13-week quarter.
Deductions
Deduction
Days/Person/Quarter
Total Days
% of Gross
PTO / Vacation
5
24.5
7.7%
Holidays
3
14.7
4.6%
Sick days (avg)
2
9.8
3.1%
On-call rotation
2.5
12.3
3.8%
Support escalations
3
14.7
4.6%
Sprint ceremonies
3
14.7
4.6%
1:1s and team meetings
4
19.6
6.2%
Onboarding Sam
0
8.0
2.5%
Total Deductions
118.3 days
37.1%
Net Capacity
Metric
Value
Gross Capacity
318.5 person-days
Total Deductions
-118.3 person-days
Net Available Capacity
200.2 person-days
Net as % of Gross
62.9%
Allocation by Work Type
Work Type
% of Net
Person-Days
Notes
New features
65%
130
Three roadmap initiatives
Tech debt
25%
50
Database migration + API cleanup
Unplanned buffer
10%
20
Support, bugs, urgent requests
Total
100%
200
Initiative Capacity Match
Initiative
Effort
Assigned
Fits?
API v3 Migration
55 days
Alex, Jordan
Yes
Self-Serve Dashboard
45 days
Riley, Casey
Yes
Webhook Reliability
25 days
Jordan, Sam
Yes
Total Planned
125 days
Available (Features)
130 days
Delta
+5 days
Under (small buffer)
Key Takeaways
Actual available capacity is typically 55-70% of theoretical capacity. Plan for this, not the fantasy number.
Track your deductions for 2-3 quarters to build accurate baselines. Guessing meeting load is always wrong.
Keep a 10% unplanned buffer. If you use less than half of it, great. If you use all of it, you planned correctly.
New hires are not at full capacity for 4-8 weeks. Model their ramp-up explicitly, not as a footnote.
Shared team members (split across teams) are less efficient than the FTE math suggests. A 0.5 FTE shared person delivers about 0.4 FTE of value due to context switching.
Review capacity vs. actuals at the end of each quarter. Refine your deduction estimates over time.
Frequently Asked Questions
How accurate does the capacity model need to be?+
Within 10-15% is good enough. The goal is not precision. The goal is to avoid committing to 150% of your capacity, which is what happens without any model at all. Refine your deduction estimates each quarter as you gather data.
What if leadership doesn't accept the capacity constraints?+
Show the math. Present the deductions with data from prior quarters. Then offer trade-offs: "We can deliver initiatives A and B at full scope, or A, B, and C at reduced scope. Which do you prefer?" The [MoSCoW prioritization framework](/frameworks/moscow-prioritization) helps structure these conversations.
Should I count story points or person-days?+
Either works, but person-days are easier for non-engineering stakeholders to understand. If your team uses story points, maintain a conversion ratio (e.g., 1 story point = 0.5 person-days) based on historical velocity.
How do I account for context-switching between initiatives?+
Add a 10-15% overhead per person for every additional initiative they're split across. Someone working on 3 initiatives simultaneously is roughly 25-35% less productive than someone focused on one.
Explore More Templates
Browse our full library of PM templates, or generate a custom version with AI.
