What This Template Is For
Overcommitting a team is the most common way to derail a product roadmap. Features slip, quality drops, and burnout accumulates. Yet most product managers plan features without formally assessing whether the team has the capacity, skills, and bandwidth to deliver them.
This template provides a structured approach to resource allocation that product managers and engineering managers can use together. It covers team composition, skill mapping, sprint-level capacity calculations, project assignments, and utilization tracking. Whether you are planning a single sprint or an entire quarter, this template helps you match ambition to reality.
Use this alongside your product roadmap to ensure every roadmap item has the staffing to actually ship. The RICE Calculator helps you prioritize what to build. This template helps you determine whether you can build it with the team you have.
How to Use This Template
- Complete the Team Roster and Skill Matrix first. This is your supply side.
- List planned projects and their resource requirements. This is your demand side.
- Calculate available capacity for the planning period (sprint, month, or quarter).
- Assign people to projects, checking for conflicts and overallocation.
- Review utilization rates. Target 70-80% allocation (not 100%).
- Revisit weekly during standups to adjust for actuals vs. plan.
The Template
Team Roster
| Name | Role | Team | FTE | Location / Timezone | Start Date | Notes |
|---|---|---|---|---|---|---|
| [Name] | [e.g. Senior Frontend] | [Squad name] | [1.0 / 0.5] | [Timezone] | [Date] | [PTO, ramp-up, etc.] |
| [Name] | [Role] | [Squad] | [FTE] | [Timezone] | [Date] | [Notes] |
| [Name] | [Role] | [Squad] | [FTE] | [Timezone] | [Date] | [Notes] |
| [Name] | [Role] | [Squad] | [FTE] | [Timezone] | [Date] | [Notes] |
| [Name] | [Role] | [Squad] | [FTE] | [Timezone] | [Date] | [Notes] |
Total headcount: [N]
Total FTEs: [N]
Skill Matrix
Map team skills to identify strengths, gaps, and bus-factor risks.
| Name | Frontend | Backend | Mobile | Data/ML | DevOps | Design | Domain Expert |
|---|---|---|---|---|---|---|---|
| [Name] | Strong | Medium | - | - | Medium | - | Payments |
| [Name] | - | Strong | - | Strong | - | - | Search |
| [Name] | Medium | - | Strong | - | - | - | Mobile UX |
| [Name] | - | - | - | - | Strong | - | Infrastructure |
| [Name] | - | - | - | - | - | Strong | Design systems |
Skill legend: Strong = can lead and mentor. Medium = can contribute independently. Weak = needs support. Dash = not applicable.
Skill gaps identified:
- ☐ [Skill area]: [Number of people at Strong/Medium level vs. needed]
- ☐ [Skill area]: [Gap description]
- ☐ [Skill area]: [Gap description]
Bus-factor risks (skills held by only one person):
- ☐ [Skill/domain]: [Person name]
- ☐ [Skill/domain]: [Person name]
Capacity Calculation
Per-Sprint Capacity (2-week sprint)
| Name | Working Days | PTO / Holidays | Meetings / Overhead | Available Days | Story Points Velocity |
|---|---|---|---|---|---|
| [Name] | 10 | [N] | [N] | [N] | [N] |
| [Name] | 10 | [N] | [N] | [N] | [N] |
| [Name] | 10 | [N] | [N] | [N] | [N] |
| Team Total | - | - | - | [N] | [N] |
Overhead assumptions:
- Sprint ceremonies: [N hours/sprint]
- On-call rotation: [N people, N% capacity impact]
- Tech debt / maintenance: [N% of capacity reserved]
- Support escalations: [N% of capacity reserved]
Net available capacity: [Total - overhead = N story points or N person-days]
Quarterly Capacity
| Month | Working Days | Team PTO Days | Holidays | Net Available Days | Planned Capacity |
|---|---|---|---|---|---|
| [Month 1] | [N] | [N] | [N] | [N] | [N story points] |
| [Month 2] | [N] | [N] | [N] | [N] | [N story points] |
| [Month 3] | [N] | [N] | [N] | [N] | [N story points] |
| Quarter Total | - | - | - | [N] | [N] |
Project Resource Requirements
| Project | Priority | Required Skills | Estimated Effort | Duration | Min. Team Size | Dependencies |
|---|---|---|---|---|---|---|
| [Project A] | P1 | Frontend, Backend, Design | [N story points] | [N sprints] | [N people] | [Blockers] |
| [Project B] | P1 | Backend, Data/ML | [N story points] | [N sprints] | [N people] | [Blockers] |
| [Project C] | P2 | Frontend, Mobile | [N story points] | [N sprints] | [N people] | [Blockers] |
| [Project D] | P3 | Full-stack | [N story points] | [N sprints] | [N people] | [Blockers] |
Total demand: [N story points]
Total supply: [N story points]
Surplus / Deficit: [+/- N story points]
Assignment Matrix
| Name | Project A | Project B | Project C | Project D | Maintenance | On-Call | Total Allocation |
|---|---|---|---|---|---|---|---|
| [Name] | 60% | - | - | - | 10% | 10% | 80% |
| [Name] | - | 50% | 20% | - | 10% | - | 80% |
| [Name] | 30% | - | 40% | - | 10% | - | 80% |
| [Name] | - | 40% | - | 30% | - | 10% | 80% |
| [Name] | - | - | - | - | 20% | - | 20% |
Allocation rules:
- No individual should exceed 80% allocation (leave buffer for unplanned work)
- No individual should be split across more than 2 major projects
- Every project must have at least one person at 40%+ allocation (an "anchor")
Utilization Dashboard
Track actual utilization weekly to catch overallocation early.
| Week | Planned Capacity | Actual Utilized | Utilization Rate | Unplanned Work | Notes |
|---|---|---|---|---|---|
| Week 1 | [N] | [N] | [%] | [N hours] | [Context] |
| Week 2 | [N] | [N] | [%] | [N hours] | [Context] |
| Week 3 | [N] | [N] | [%] | [N hours] | [Context] |
| Week 4 | [N] | [N] | [%] | [N hours] | [Context] |
Target utilization range: 70-80%
- Below 70%: Team may be underutilized. Look for opportunities to pull work forward.
- 70-80%: Healthy range with buffer for unplanned work and learning.
- Above 80%: Risk zone. Quality and morale will degrade. Cut scope or add capacity.
- Above 90%: Crisis. Something must give. Escalate to leadership.
Workload Balancing Actions
When demand exceeds supply, use these levers:
| Action | Impact | Timeline | Decision Owner |
|---|---|---|---|
| Defer P3 projects to next quarter | Frees [N] story points | Immediate | PM |
| Reduce scope of [Project C] to MVP | Frees [N] story points | 1 sprint | PM + Eng Lead |
| Request contractor for [skill] | Adds [N] story points after ramp | 2-4 weeks | Eng Manager |
| Cross-train [Name] on [skill] | Adds flexibility in [N] weeks | 4-6 weeks | Eng Manager |
| Negotiate deadline extension for [Project B] | Reduces sprint pressure | Immediate | PM + Stakeholder |
Quarterly Review
| Metric | Target | Actual | Trend |
|---|---|---|---|
| Average utilization | 70-80% | [%] | Up / Down / Stable |
| Planned vs. delivered | 80%+ | [%] | Up / Down / Stable |
| Unplanned work ratio | <20% | [%] | Up / Down / Stable |
| Context-switching frequency | <2 projects/person | [N] | Up / Down / Stable |
| Team satisfaction (survey) | >7/10 | [N] | Up / Down / Stable |
Tips for Better Resource Allocation
Plan at 70-80%, not 100%. Every sprint has unplanned work: production incidents, support escalations, scope clarifications, meetings that run long. If you plan at 100%, any disruption puts the sprint at risk. Use the sprint planning template to apply this buffer consistently.
Minimize context switching. Research shows that switching between projects reduces productivity by 20-40% per additional project. Assign people to no more than 2 projects. One anchor person per project at 40%+ allocation creates ownership and reduces coordination cost.
Track unplanned work as a category. If unplanned work consistently exceeds 20% of capacity, the issue is not resource allocation. It is product stability, support load, or unclear priorities. Treat the root cause using root cause analysis.
Revisit allocation weekly. A quarterly plan is a starting point, not a contract. Review allocations in your weekly team sync and adjust as priorities shift and actuals diverge from plan. The product operations handbook covers operational cadences that keep resource plans current.