Capacity, reserves, and why full sprints fail
Most capacity plans are arithmetic plus one honest judgement. The judgement is where they go wrong.
The focus factor is the honest part
Sprint days times hours per day is arithmetic. The focus factor is a judgement, and it is where most capacity plans fail.
It covers everything that is real work but not sprint work: production support, code review, interviewing, helping another team, and the twenty minutes after an interruption before you are properly thinking again. Teams new to measuring it typically guess 0.9 and discover 0.6.
Find yours by looking backwards. Take last sprint's committed hours over the hours theoretically available, three or four times over. The result is about your team rather than about optimism.
Never convert points to hours
Story points work because they are relative and local: this is about twice that. That property survives someone being faster, having a bad week, or being new to the codebase.
Convert to hours and you have thrown all of it away, and you now have a number that looks like a commitment and behaves like an estimate. If you want hours, estimate in hours. If you want relative sizing, size in points and forecast from throughput. Doing both gets the disadvantages of each and the benefits of neither.
Reserve capacity before you plan, not after
Every team knows support and interruption will arrive. Most sprint plans are built as though they will not, and the result is a sprint full on day one and late by day three — the unplanned work done anyway, the committed work quietly dropped.
Reserving capacity up front changes what gets committed rather than what gets done. The work arrives either way; the only question is whether the plan admitted it would.
A full sprint is a fragile sprint
Filling to 95% of capacity leaves nothing for the first surprise, and there is always a first surprise. Teams that hit their sprint goals consistently generally commit to noticeably less than they could.
That reads as underperformance to anyone treating the sprint plan as a productivity target, and stops reading that way the moment you have watched a fully-loaded sprint fail on something nobody could have predicted.
Do not let a tool reorder your priorities
An optimiser can fit marginally more work into a sprint by rearranging what you prioritised. That is almost never the trade you want — the most important item does not become less important because a cheaper one packs better.
Take items in priority order, stop when capacity runs out, and look at what was left behind. If something important did not fit, that is information about the sprint rather than a packing problem to solve.