Multi-Project Capacity Planning Template for Startup Teams

Multi-project planning becomes unreliable when every project has its own roadmap but the team has only one shared pool of time. The fix is not a more elaborate task list. It is a single capacity view that shows how much delivery time is actually available, where that time is allocated, and which commitment must move when demand exceeds capacity.

The multi-project capacity planning template

Use four connected views. Together they answer four different questions:

1. Team capacity: How much focused delivery time is realistically available?
2. Project demand: How much time does each project need during the planning period?
3. Allocation: Which people and skills are assigned to each project?
4. Flow guardrails: How much work may be active at the same time?

1. Team-capacity worksheet

Start with availability, not requested work. A simple planning formula is:

Planning capacity = (working hours − leave − fixed meetings − support and operational work) × chosen focus factor

The focus factor is your own planning buffer for context switching, small interruptions, and uncertainty. It is not a universal benchmark. Start with an explicit assumption, compare it with completed work, and adjust it using evidence.

These figures are deliberately conservative and purely illustrative. The important part is that every deduction is visible. Hidden support work and recurring meetings are still demand on the team, even when they never appear on a product roadmap.

2. Project-demand worksheet

List only work that may consume capacity during the selected period. Keep estimates at a level the team can discuss without pretending to know more than it does.

In this example, requested demand is 74 hours while team capacity is 57.2 hours. The table is doing its job: it exposes the conflict before the team starts. The answer is a portfolio decision, not an instruction to work faster.

3. Allocation view

Translate funded demand into a small allocation table. Keep one row per person and make the total visible.

Do not use the table to optimise every hour. Its purpose is to reveal overload, scarce skills, and fragile plans. If the same specialist is essential to three projects, team-level capacity may look healthy while that person remains the bottleneck.

4. Flow guardrails

Capacity allocation alone does not prevent the team from starting too much work. Add explicit work-in-progress controls, such as:

• No more than two active delivery projects per person.
• No new project starts while a blocked item can be unblocked.
• Expedited work must name the project that will lose capacity.
• Work older than the team’s normal cycle receives attention before new work is pulled.

The current Kanban Guide treats explicit control of work in progress as a core practice and describes WIP, throughput, work-item age, and cycle time as minimum flow metrics. Its practical implication is simple: start new work when capacity becomes available, not merely because another request appears.

How to run the planning meeting

1. Update real availability. Enter leave, on-call duties, recurring support, and fixed meetings.
2. Review the previous period. Compare planned capacity with work actually finished. Do not hide carry-over.
3. Order outcomes. Decide which business outcomes matter most before discussing individual tasks.
4. Fund projects in order. Allocate people and scarce skills until capacity is exhausted.
5. Resolve overload explicitly. Reduce scope, move a date, change ownership, or stop work.
6. Set WIP controls. Agree what can be active and how exceptions will be handled.
7. Record assumptions. Note the estimates, dependencies, and planning buffer that could change the decision.

The Scrum Guide emphasises transparency, frequent inspection, adaptation, sustainable pace, and a single objective for a Sprint. You do not need to adopt Scrum to use those principles: make the plan visible, inspect it against actual delivery, and change it when evidence changes.

What to do when demand exceeds capacity

Overload is not a spreadsheet error. It is a choice that has not yet been made. Use this decision order:

1. Remove work that does not change a meaningful outcome.
2. Reduce scope while preserving the outcome.
3. Sequence projects instead of running them simultaneously.
4. Change the date or service level.
5. Transfer work only when the recipient has the skill and capacity.
6. Add capacity last. Hiring or contracting helps only when onboarding and coordination do not consume the expected gain.

Recurring manual work deserves its own line in the capacity model. Google’s SRE guidance on toil recommends identifying and measuring repetitive operational work before deciding how to reduce it. For a startup team, that may mean tracking support triage, manual reporting, release administration, or repeated data cleanup instead of treating those hours as unexplained variance.

Copyable blank template

Copy these column headings into a spreadsheet, database, or project tool.

Team capacity

Team member | Period | Working hours | Leave | Fixed meetings | Support/operations | Focus factor | Planning capacity | Scarce skills | Notes

Project demand

Project | Outcome | Owner | Requested capacity | Critical skill | Deadline | Priority | Dependencies | Decision

Allocation

Team member | Project | Allocated capacity | WIP limit | Start condition | Stop/review condition

Weekly evidence

Period | Planned capacity | Completed work | Carry-over | Blocked time | Unplanned work | Cycle-time note | Change for next period

Common capacity-planning mistakes

• Planning from contracted hours. A 40-hour week is not 40 hours of project delivery.
• Ignoring skill constraints. Ten available people do not equal ten interchangeable people.
• Counting partially started work as progress. More active projects can create more queues and more handoffs.
• Using estimates as commitments. Estimates are decision inputs, not guarantees.
• Filling every available hour. A plan without room for uncertainty becomes obsolete at the first interruption.
• Adding urgent work without naming the trade-off. New priority work should displace something visible.

Connect the template to your project system

The template works with a spreadsheet or any project-management platform. Tool choice comes after the decision model. If you are comparing software, use the existing guide to tools for managing multiple projects. For a broader operating model, see Startup Systems & Tools and Startup Operations & Scaling.

Frequently asked questions

Should capacity be measured in hours or story points?

Use the unit that supports the decision. Hours are useful for cross-project allocation and known calendar constraints. Relative sizing can be useful within one stable team. Avoid combining points from different teams as if they were a universal unit.

How much buffer should a startup team keep?

There is no universal percentage. Choose an explicit buffer based on interruption risk and uncertainty, then compare planned work with actual delivery. Increase it when unplanned work repeatedly displaces commitments; decrease it only when evidence supports the change.

How often should the plan be updated?

Update availability whenever leave, support duty, or a major dependency changes. Review allocation at a regular cadence—often weekly for a fast-moving startup—and avoid rewriting the plan for every small fluctuation.

Can one person work across several projects?

Yes, but make the cost visible. Multiple projects add coordination and switching. Set an explicit limit on concurrent active work and sequence tasks when one specialist becomes a bottleneck.

Next step

Build the team-capacity table first. If requested project demand exceeds the total, make one explicit portfolio decision before assigning another task. A plan becomes useful when it shows what the team will not do.

Sources

• The Kanban Guide, May 2025
• The 2020 Scrum Guide
• Google Site Reliability Workbook: Eliminating Toil