Engineering Capacity Planning Template
Two documents and three sheets that forecast a delivery date as a range from historic throughput instead of one number nobody can defend.
Free download · No account needed
Forecast with Confidence Range
One row per commitment: a naive estimate next to a simulated range
Filled in once a throughput window and a backlog size both exist. The naive estimate is the number most stakeholders ask for first.
Naive Estimate
Backlog divided by the window's mean weekly throughput, rounded up. One number, no stated likelihood attached.
P50 / P85 / P95
The same backlog closed against 10,000 simulated futures drawn from the same throughput window. Three delivery weeks, each with a stated chance of holding.
Actual / Naive Result / P85 Result
Filled in once the commitment resolves, turning the sheet into a track record: how often the naive date held, and how often the 85th percentile actually covered what happened.
Every capacity planning template ranking for this query runs the same arithmetic: gross hours per person, minus PTO and holidays, minus a fixed non-project allowance, divided into the backlog for one committed date. A 1994 study on how people predict their own task completion times found predictions built this way, from a plan rather than a track record, are reliably too optimistic. None of these templates state how likely their one date actually is, which is exactly the number a stakeholder needs once that date starts to move.
This pack forecasts from the team's own trailing throughput instead. Broadcom's own documentation for the Rally Delivery Forecast Tool describes the same technique: sample a team's historical throughput thousands of times for a delivery date at a stated confidence level. At Osprey Robotics, a fictional robotics software company, a naive point estimate missed the promised date in 2 of the team's last 6 release commitments. The 85th-percentile forecast missed only once, a 16.7 percent miss rate against the roughly 15 percent an 85th percentile is supposed to miss.
The Capacity Model sheet still runs the roster math, on purpose: for Osprey's 5-person team it predicts 7.48 tickets a week, while the trailing 12-week measured throughput is 5.25, a 29.8 percent gap the roster arithmetic cannot see. The current, unresolved forecast reads P85: 11 weeks against that same window. Built for the engineer defending a date next to the technical program plan tracking the same commitments and the technical risk register covering what happens when one slips.
What's in the pack
Estimation Approach
Why a single date is the wrong output, what the simulated forecast does differently, and how to read a percentile as a stated likelihood instead of a promise.
Assumption Note
The four conditions this forecast depends on, checked against the team's own data instead of listed as generic caveats, including the one window that broke it.
Historic Throughput and Cycle Time
The trailing 12-week window: tickets closed and median cycle time by week, with a flag for any week a real change makes older data a bad guide.
Capacity Model
The roster math done in full, headcount to net modeled capacity, then measured against real throughput so the gap between the two has a number attached.
Forecast with Confidence Range
The naive estimate and the simulated 50th, 85th and 95th percentile side by side, plus a running track record of which one actually held.
How it works
- 1
Open in River, or take it blank
Claim the pack in River and hand it a ticket export and your roster, or take the blank documents and sheets and fill them in yourself.
- 2
Send the export and roster
A raw ticket export with close dates, plus headcount, on-call rotation and standing meeting load. Partial and messy is normal; missing columns get flagged, not guessed.
- 3
Get the history and capacity model
River buckets closed tickets into weekly throughput, computes cycle time, and builds the roster-based capacity model next to it so the gap between the two is a real number.
- 4
Forecast the next commitment
Send a backlog size and get the naive estimate next to the 50th, 85th and 95th percentile delivery week, plus the running track record of how often each has held.
Frequently asked questions
Is this template free?
Yes, no account or card needed to download it. Edit with AI is the optional half, where River reads your ticket export and roster and builds the throughput history, capacity model and forecast itself. Every other pack in the template library works the same way.
What format are the downloaded files?
Two documents as Word files and three sheets as CSVs, zipped together. The sheets ship with Osprey Robotics' illustrative throughput history and track record already in place, so the naive-versus-percentile comparison is visible before you replace the rows with your own team's data.
What does Edit with AI actually do?
It reads your ticket export and builds the throughput and cycle-time history, then asks about headcount and on-call load to build the Capacity Model. Send a backlog size and it runs the naive estimate and the simulated forecast, reporting the 50th, 85th and 95th percentile delivery week.
Why not just use a roster-based capacity spreadsheet?
A roster spreadsheet answers what the team should produce. This pack measures what it actually has, and Osprey Robotics' own numbers show why that matters: the roster predicted 7.48 tickets a week against a measured 5.25, a 29.8 percent gap invisible to hours-minus-PTO arithmetic alone.
What does an '85th percentile' delivery date actually mean?
It is the delivery week by which 85 percent of ten thousand simulated futures, each built from your team's own throughput history, finished the backlog. It is meant to miss sometimes, roughly one commitment in six to seven. A number that never misses is set too wide to plan around.
Does this replace our program management tool?
No. The technical program plan runs the cross-team handoffs a date depends on, and the engineering status update reports it upward once committed. This pack is where the committed date itself gets built, from measured throughput rather than a roster guess. Whether to build the estimated work at all, instead of buying it, is an earlier decision: see a build vs buy decision.
Our ticket data can't leave our network. Can we still use this?
Yes. A private AI workspace builds the throughput history, capacity model and forecast inside your own tenancy. No ticket export, roster or roadmap detail crosses a boundary your security team has not already reviewed and approved for internal delivery data like this.
Turn your throughput history into a date you can defend
Send the ticket export and the roster. River builds the throughput history, the capacity model, and a forecast that states a confidence level instead of a single number.
Edit with AI