Capacity math and forecasting with percentiles
What it is
Two related answers a lead has to give in numbers rather than adjectives: how much can this team take on, and when will this be done.
Capacity math is the honest conversion from headcount to available project work, plus a declared split of that work across categories. Forecasting with percentiles replaces estimation with measurement: you sample the team's actual historical throughput and simulate forward, producing a date distribution rather than a date.
The two things people say, and what to say instead:
"We have 7 engineers, so we have 7 engineers of capacity."
-> ~3.5 to 4.5 engineers of project capacity, and here is the
arithmetic.
"That'll take about six weeks."
-> "P50 is 24 March, P85 is 11 April, assuming scope is frozen
and the team stays at 7. Each additional must-have of this
size moves P85 by about a week."
What this is confused with: estimation. An estimate is a forecast produced by opinion. A percentile forecast is produced from the team's own delivery history, which means it already contains the interruptions, the sick days and the underestimation bias, none of which an estimate contains.
Also confused: velocity and capacity. Velocity is an output measurement in a unit (points) that is not comparable across teams and drifts within one. Capacity is an input budget in person-days. Forecasting from throughput in items per week avoids the points question entirely.
The problem it solves
Two failures, and they compound into the same outcome: a team that looks slow and a lead who cannot explain why.
Failure 1: unbudgeted work.
Team of 7. Commitments made as if 7 people work on the roadmap.
What actually happens in a week:
on-call 1 person, largely consumed
interrupts and support ~8 person-days across the team
security patching, library
and platform upgrades ~3 person-days
interviews, onboarding ~2 person-days
meetings and ceremony ~5 person-days
vacation/holiday (annual
average) ~3 person-days
35 nominal person-days - 26 = 9 person-days of roadmap work.
The roadmap was planned against 35. The team delivers 9. Everyone
concludes the team is slow, including the team.
The work did not disappear; it was never on the plan. And because it was never on the plan, it is invisible in every conversation about why delivery is behind.
Failure 2: point estimates.
"Six weeks" is a single number with no probability attached, so:
- the stakeholder hears a commitment
- the team hears an aspiration
- nobody knows whether it is a 50% date or a 90% date
- when it slips, the conversation is about trust rather than
about the distribution
And cycle time is right-skewed, so the mean is not the middle:
cycle times (days), 40 recent items:
1,1,2,2,2,3,3,3,3,4,4,4,4,5,5,5,6,6,6,7,7,8,8,9,9,10,11,12,
13,14,16,18,21,24,28,33,41,52,68,91
mean 14.2 median 6 P85 28 P95 60
A plan built on the mean is wrong in both directions: too
pessimistic for the typical item, wildly optimistic for the tail.
Mechanics
Capacity: the arithmetic
Start from nominal, subtract what is committed elsewhere.
N engineers x 5 days = nominal person-days/wk
minus vacation + statutory holidays
(Ontario: ~2 weeks vacation + 9
statutory days = ~19/260 days
= 7.3%) ~ 7%
minus sick and personal ~ 3%
minus meetings and ceremony 10-20%
minus on-call (1 person, partly) 1/N of headcount
minus interrupts and support measure it
minus hiring, interviews, onboarding measure it
minus KTLO: upgrades, patches, compliance measure it
FOCUS FACTOR = project days / nominal days.
Measured values in healthy teams: 0.50 to 0.65.
Anything above 0.70 usually means something is not being counted.
The number to defend is not the focus factor, it is the measurement. Estimating it produces an argument; measuring it for four weeks produces a fact.
How to measure it cheaply, without a timesheet culture:
- label every ticket with one of the three buckets (below)
- once a week, ask each person for a one-line split of their
week in tenths. Takes 30 seconds each.
- or sample: pick two random half-days a week and record what
the team was doing.
Any of these beats an estimate, and the second one is the cheapest
that survives contact with a busy team.
The three-bucket budget
FEATURE new capability, roadmap work, experiments
RELIABILITY tech debt, refactoring, test infrastructure,
& INVESTMENT performance, developer experience, migrations
KTLO support, incidents, on-call follow-up, dependency and
platform upgrades, security patching, compliance,
deprecation forced on you by other teams
A declared allocation, e.g. 60 / 20 / 20, reviewed quarterly.
The value is not the specific numbers, it is that the split is declared and then measured against reality.
The artifact that changes the conversation:
declared actual (last quarter)
Feature 60% 38%
Reliability 20% 9%
KTLO 20% 53%
Reading: KTLO consumed 2.7x its budget, and it came out of both
other buckets. The team did not underdeliver on features by 22
points because it was slow.
The follow-up question is then the useful one: WHY is KTLO 53%,
and what would reduce it? In one case: 31 of the 53 points were
dependency upgrades forced by a platform team's deprecation
schedule, which was a cross-team negotiation, not a team
performance problem.
Presenting declared-versus-actual reframes "why are you behind" into "here is where the capacity went, and here is the decision I need from you." That reframing is most of the lead's job in a planning conversation.
Guardrails on the buckets:
- KTLO going up over time is the signal that reliability
investment is too low. They trade against each other with a lag
of a quarter or two.
- If reliability is the bucket that gets raided every time
something is urgent, it is not a budget, it is a wish. Protect
it by scheduling it as named work with owners, not as slack.
- A quarter with 0% reliability is a decision. Make it
explicitly, with an expiry date, and say what it costs.
Forecasting: throughput and Monte Carlo
Stop summing estimates. Sample history.
import random
def forecast(weekly_throughput: list[int], remaining_items: int,
trials: int = 10_000) -> dict[str, int]:
"""Monte Carlo forecast of weeks-to-completion.
weekly_throughput: items completed per week, from the team's
own history. 10 to 20 weeks is enough; more than ~26 starts
including a team that no longer exists.
remaining_items: count of items left. NOT points. The count is
sufficient because the historical throughput already
encodes the size distribution.
"""
results = []
for _ in range(trials):
done, weeks = 0, 0
while done < remaining_items:
# Resample an actual past week. This carries the real
# variance: holiday weeks, incident weeks, good weeks.
done += random.choice(weekly_throughput)
weeks += 1
results.append(weeks)
results.sort()
return {
"P50": results[len(results) // 2],
"P85": results[int(len(results) * 0.85)],
"P95": results[int(len(results) * 0.95)],
}
Example. Last 14 weeks of completed items:
[6, 4, 9, 3, 7, 5, 0, 8, 6, 5, 11, 4, 7, 6]
(the 0 was an incident week; leave it in, it is real)
Remaining: 62 items.
forecast(history, 62) -> {'P50': 11, 'P85': 14, 'P95': 16}
Reported as: "Half the time we finish in 11 weeks. 85% of the time
within 14. There is a 5% chance it takes 16 or more. The zero-week
in our history is an incident week, and the simulation includes
the possibility of another one."
Why this beats estimate-summing:
- It uses the team's real variance, including the bad weeks.
- It requires no estimates at all, only a count of remaining
items, which removes the estimation meeting.
- It produces a probability, so the stakeholder chooses their own
risk tolerance rather than inheriting yours.
- It is trivially re-runnable weekly, so the forecast improves as
the work proceeds instead of being defended.
The two inputs it needs, and the honest caveats:
1. A stable-ish item size. If items range from an hour to a
month, resampling breaks. The fix is not estimation, it is
splitting: cap item size at "a few days" and the distribution
tightens on its own.
2. A known remaining COUNT. Scope discovery is the real
uncertainty, and it is modelled by a split factor:
"62 known items, and historically discovery adds 20-40%,
so simulate 74 to 87."
State the split factor separately, because it is the
assumption most likely to be wrong.
Little's Law, and why cutting WIP is the lever
WIP
cycle time = --------
throughput
20 items in progress, 4 completed per week
-> average cycle time = 5 weeks
Cut WIP to 8, throughput unchanged
-> average cycle time = 2 weeks
Throughput usually goes UP when WIP goes down, because context switching and blocked-item overhead fall, but the law holds even if it does not: cutting WIP shortens cycle time arithmetically, and it costs nothing.
And the measurement that explains why:
FLOW EFFICIENCY = active time / total elapsed time
Typical measured values: 5% to 20%.
An item with a 20-day cycle time and 15% flow efficiency spent
3 days being worked on and 17 days waiting: for review, for a
dependency, for a decision, for an environment, for a deploy
window.
So "work faster" addresses 3 days out of 20. Removing queues
addresses 17.
This is the single most useful number a lead can produce, because it redirects an improvement conversation from effort to flow, and because 15 percent is a shocking enough number to be remembered.
Answering "when will it be done"
Never a bare date. The shape that works:
"P50 is 24 March, P85 is 11 April. That assumes:
- scope is the 62 items currently in the plan, and history
says discovery adds 20 to 40 percent
- the team stays at 7 with the current on-call load
- the payments dependency lands by 3 March; if it slips a
week, P85 moves about a week
If you need 24 March at high confidence, the levers are:
cut 15 items, or add the two contractors we discussed, which
historically takes 4 to 6 weeks to show up in throughput."
Three properties make that answer defensible: a probability, the assumptions, and the levers. A date with no probability is a promise; a date with a probability is a forecast; a forecast with levers is a decision the stakeholder can participate in.
A worked example: a team that was not slow
A platform team of 7 engineers. Two quarters of missed roadmap commitments. The VP's framing entering the conversation was "the team's velocity has dropped and I need to understand why."
Four weeks of measurement, using the 30-second weekly split:
Nominal: 7 x 5 = 35 person-days/week
Measured average per week:
on-call primary (1 person) 4.1 days consumed
interrupts, support, Slack asks 6.8 days
meetings, ceremony, planning 5.2 days
interviews and onboarding 2.4 days
vacation/holiday/sick 2.6 days
dependency and security upgrades 3.9 days
-------------------------------------------
non-project total 25.0 days
ROADMAP CAPACITY 10.0 days/week
Focus factor: 10/35 = 29%.
Twenty-nine percent is far below the 50 to 65 percent healthy band, which made the number an argument rather than an excuse.
Three-bucket split, from ticket labels over the previous two quarters:
declared Q1 actual Q2 actual
Feature 65% 41% 33%
Reliability 15% 7% 4%
KTLO 20% 52% 63%
KTLO rising from 52 to 63 percent across two quarters, with reliability falling to 4 percent, is the lagged trade in the guardrail above happening in real time.
Where the KTLO came from, itemised:
Of the 63 points of KTLO in Q2:
27 dependency upgrades forced by the platform org's
deprecation schedule (4 major runtime and framework
upgrades in one quarter)
16 support requests from 9 consuming teams, none of which had
a self-serve path
11 incident follow-up
6 compliance evidence collection
3 miscellaneous
Each line has a different owner and a different fix, which is the point of itemising rather than reporting a single KTLO number.
The three asks the lead made, each attached to a number:
1. "Four forced major upgrades in one quarter is 27 points of our
capacity. Can the platform org stagger them across two
quarters?"
-> agreed. Two moved to Q3.
2. "Nine teams ask us the same six questions. 16 points a quarter
is 1.1 engineers. Building the self-serve path is estimated
at 3 weeks of one engineer, so it pays back in under a
quarter."
-> approved as named reliability work with an owner.
3. "Our on-call is a 4-person rotation, so each person is on call
one week in four and loses most of it. Moving to a 7-person
rotation across the two teams costs onboarding and returns
~2 person-days a week."
-> deferred, revisited the following quarter.
Forecasting replaced the estimation meeting:
Before: a 3-hour estimation session per quarter, 7 people, output
a point total and a date. 21 person-hours, and the date
was wrong both quarters.
After: count remaining items, run the simulation, report P50/P85.
Re-run weekly, taking about 10 minutes.
First forecast, at the start of Q3:
history (last 12 weeks completed): [5,3,8,2,6,4,7,5,6,3,9,4]
remaining: 48 known items, discovery factor 25-40%
-> simulate 60 to 67
at 60 items: P50 = 12 weeks, P85 = 15
at 67 items: P50 = 13 weeks, P85 = 17
Reported: "P85 is 17 weeks, which is past the quarter. To land
inside the quarter at P85 we need to be at about 45 items, so
15 to 22 items have to come out. Here is the list, ranked by my
read of value; I need you to choose."
The last sentence is what changed the relationship. The lead stopped defending a date and started presenting a scoping decision with a probability attached to each option.
And the flow-efficiency measurement, which produced the largest single improvement:
Sampled 30 completed items: elapsed time vs active time.
median cycle time 14 days
median active time 2.5 days
FLOW EFFICIENCY 18%
Where the 11.5 waiting days went:
4.1 waiting for code review
3.2 waiting for a dependent team's API
2.0 blocked on a decision
1.4 waiting for a deploy window
0.8 waiting for a test environment
Actions:
- a review SLA (first response within 4 working hours), plus a
daily 20-minute review slot on everyone's calendar
- deploy windows removed for this service (a separate
conversation, using the deployment-strategy capacity
arithmetic)
- a standing 15-minute weekly decision slot with the PM and
the architect, with a written list
Six weeks later:
median cycle time 14 -> 8 days
flow efficiency 18% -> 31%
throughput 5.2 -> 7.1 items/week
Nobody worked harder or longer.
Throughput rose 37 percent from removing queues, which is the concrete demonstration that the lever is flow and not effort.
Outcome after two quarters:
before after
focus factor 29% 44%
KTLO share 63% 38%
reliability share 4% 17%
median cycle time 14 days 8 days
roadmap items per
quarter 41 68
forecast accuracy n/a 3 of 3 quarters landed inside
the P85 date
Forty-four percent is still below the healthy band and was reported as such, because the honest version of the story is that the team went from badly constrained to normally constrained, and claiming otherwise would have made the next quarter's asks harder to justify.
Production evidence
Little's Law is a theorem of queueing theory (Little, 1961) that holds for any stable system regardless of arrival distribution or service discipline, which is why cutting WIP shortens cycle time arithmetically rather than as an empirical tendency.
Daniel Vacanti's Actionable Agile Metrics for Predictability and Troy Magennis's forecasting work are the standard references for throughput-based Monte Carlo forecasting and for reporting percentiles rather than point estimates; both make the argument that item count plus historical throughput outperforms estimate-summing.
The Kanban community's flow metrics (cycle time, throughput, work in progress, flow efficiency, work item age) are the standard set, and flow efficiency measurements in the 5 to 20 percent range are consistently reported across organisations, which is what makes "most of cycle time is waiting" a general finding rather than one team's problem.
The DORA research programme measures lead time for changes as one of its four key metrics, and its consistent finding that batch size and WIP reduction correlate with delivery performance is the large-sample version of the flow argument.
Google's SRE practice of capping operational work at 50 percent is the best-known formal budget for one of these buckets, and the enforcement mechanism, overflow returns to the development team, is the part most imitations omit.
Ontario's Employment Standards Act sets the statutory vacation and public holiday entitlements that put a floor under the availability subtraction for a Toronto-based team, which is why the 7 percent figure is a legal fact rather than a planning assumption.
The debate
Story points or item counts? Item counts, forecast by Monte Carlo. Points attempt to normalise size so that summing works, and the normalisation is exactly the thing teams cannot do reliably; resampling historical throughput needs no normalisation because the size distribution is already in the history. The counter-argument, that points force a useful conversation about complexity, is real and is better served by splitting items until they are small, which tightens the distribution as a side effect.
Is a focus factor demoralising to publish? The opposite, in practice. A team told it is delivering 29 percent of nominal capacity hears an accusation; a team shown that 25 of 35 person-days are consumed by named, itemised, mostly external commitments hears an explanation. The risk is publishing the aggregate without the itemisation, which invites "so make the meetings shorter."
Should reliability be a fixed percentage? A declared percentage, defended, and revisited quarterly. The counter-argument, that reliability work should be justified case by case, sounds rigorous and fails in practice because each individual case loses to a feature with a date. A budget converts many losing arguments into one winnable one, which is the same reasoning as an error budget.
Do percentile forecasts survive contact with executives? Better than point estimates, provided you lead with one number. Report P85 as "the date," mention P50 as the optimistic case, and never present a distribution without a recommended commitment, because an executive asked to choose a percentile will reasonably ask what you would choose.
Is measuring flow efficiency worth the effort? For one sample of 30 items, yes, decisively. Continuous measurement is usually not worth it, because the number rarely moves without intervention and the actions it implies (review SLA, decision cadence, dependency management) are durable once taken. Measure it, act, re-measure in a quarter.
Does adding people help a late project? Not inside the forecast horizon, and the honest number is the ramp: new engineers typically show up in throughput after 4 to 8 weeks, and until then they consume the throughput of whoever onboards them. Say the ramp cost out loud, because "add people" is otherwise the first lever a stakeholder reaches for.
Follow-up Q&A
"How much capacity does a team of seven actually have?"
Roughly 10 to 22 person-days a week of project work out of 35 nominal, depending on load. Subtract vacation and statutory holidays, about 7 percent in Ontario; sick and personal, about 3; meetings and ceremony, 10 to 20; on-call, which consumes most of one person's week; and then the categories you have to measure rather than assume: interrupts and support, hiring and onboarding, and forced upgrades. A healthy focus factor is 50 to 65 percent. Anything above 70 usually means something is not being counted, and the number only carries weight if it is measured rather than estimated, which a weekly 30-second split per person is enough to do.
"What is the three-bucket budget for?"
To make the split between feature work, reliability investment and keeping-the-lights-on explicit, so that it can be compared against reality. The artifact that changes a planning conversation is declared-versus-actual: 60/20/20 declared against 38/9/53 actual says the team did not underdeliver on features by 22 points because it was slow, it did so because KTLO consumed 2.7 times its budget. Then the useful question is why, which needs the KTLO itemised, because forced dependency upgrades, support requests from consuming teams and incident follow-up have different owners and different fixes.
"How do you forecast without estimates?"
Resample the team's own weekly throughput. Take 10 to 20 weeks of items-completed-per-week, count the remaining items, and simulate: repeatedly draw random past weeks until the remaining count is consumed, and record how many weeks it took. Ten thousand trials gives a distribution, and you report P50, P85 and P95. It needs no estimates because the historical throughput already contains the size distribution, the interruptions and the bad weeks, including the incident week that shows as a zero. The two real assumptions are that item sizes are roughly stable, which you get by splitting rather than estimating, and the scope discovery factor, which you state separately because it is the assumption most likely to be wrong.
"Why is cutting work in progress the lever?"
Little's Law: cycle time equals WIP divided by throughput, and it holds for any stable system. Twenty items in progress at four completions a week is a five-week average cycle time; cutting to eight items makes it two weeks, arithmetically, with no change in how fast anyone works. Throughput usually rises as well because context switching and blocked-item overhead fall, but the shortening does not depend on that. It is the rare intervention that is free and immediate.
"What does flow efficiency tell you?"
The fraction of an item's elapsed time that was active work, typically 5 to 20 percent. An item with a 14-day cycle time and 18 percent efficiency spent about 2.5 days being worked on and 11.5 days waiting, for review, for a dependency, for a decision, for a deploy window, for an environment. That redirects the improvement conversation from effort to queues: working faster addresses 2.5 days, removing queues addresses 11.5. In one case a review SLA, a weekly decision slot and removing deploy windows took median cycle time from 14 days to 8 and throughput from 5.2 to 7.1 items a week, with nobody working longer.
"How do you answer 'when will it be done'?"
With a probability, the assumptions, and the levers. "P50 is 24 March, P85 is 11 April, assuming scope stays at the current 62 items with a historical discovery factor of 20 to 40 percent, the team stays at seven, and the payments dependency lands by 3 March. If you need 24 March at high confidence, the levers are cutting about 15 items, and here is my ranking, or adding people, which historically shows up in throughput after four to six weeks." A date without a probability is a promise; with one it is a forecast; with levers it is a decision the stakeholder makes with you.
Common misconceptions
"Seven engineers means seven engineers of capacity." It means roughly three and a half to four and a half, and the difference is itemisable.
"Velocity measures productivity." It measures output in a unit that is not comparable across teams and drifts within one. Throughput in items, plus resampling, avoids the question.
"Estimate better." Estimation error is not the main source of forecast error; scope discovery and variance are, and both are handled by a distribution rather than by a better point estimate.
"The mean cycle time is the typical cycle time." Cycle time is right-skewed, so the mean sits well above the median and describes neither the typical item nor the tail.
"Work faster." With flow efficiency at 15 percent, effort addresses 15 percent of elapsed time. Queues are the other 85.
"Add people to catch up." New engineers reduce throughput for four to eight weeks before they add to it, which usually places the benefit after the date you were trying to hit.
Interview delivery note
Say this verbatim: "A team of seven has about four engineers of project capacity, and the way to make that credible is declared-versus-actual on three buckets. Sixty-twenty-twenty declared against thirty-eight, nine, fifty-three actual turns 'why are you behind' into 'here is where the capacity went and which of these do you want me to change'." It shows you convert a performance accusation into a resourcing decision with an artifact.
The senior-versus-staff separator is flow efficiency. A senior lead reports cycle time. A staff lead samples 30 items, finds that 2.5 of 14 days were active work, itemises where the other 11.5 went, review queues, dependency waits, decision latency, deploy windows, and then fixes the queues rather than the effort. Reporting that throughput rose 37 percent with nobody working longer is the version of this that persuades, because it makes the lever visible.
The second signal is refusing to give a bare date. Answering with P50 and P85, the assumptions behind them, and the specific levers with their costs, including that added people take four to eight weeks to appear in throughput, moves the conversation from a commitment you will be held to into a scoping decision the stakeholder makes with you.
Further reading
- Daniel Vacanti, Actionable Agile Metrics for Predictability, for throughput-based forecasting and the flow metric set.
- Troy Magennis's forecasting materials and Monte Carlo spreadsheets, for the simulation approach with split factors for scope discovery.
- Little, "A Proof for the Queuing Formula L = λW" (1961), for why the WIP relationship holds independent of distribution.
- Google's SRE Book on the 50 percent cap on operational work, including the overflow mechanism.
- The metrics a lead watches page, for how these numbers sit alongside the DORA set.