What can the team actually take?
Days off, part-time allocations, ceremonies and the fact that nobody spends eight hours a day on sprint work. Hours only — there is no honest points conversion.
What the team can actually take on
Hours, honestly counted — days off, part-time allocations, ceremonies and the fact that nobody spends eight hours a day on sprint work.
The team
How this counts
gross = (sprint days − days off) × hours per day × allocation
effective = (gross − ceremonies) × focus factor
Ceremonies are scaled by allocation, since a half-time person attends roughly half of them.
No conversion to story points is offered. There is no hours-per-point rate to convert with. Points measure relative size within one team, and pinning them to hours destroys the only property that makes them useful — that they are insulated from who does the work and how fast.
The focus factor is where the honesty lives
Everything else on this page is arithmetic. The focus factor is a judgement, and it is where most capacity plans go wrong.
It covers everything that is real work but not sprint work: production support, code review, interviewing, helping another team, the meeting nobody scheduled, 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.
The way to find yours is to look backwards: take last sprint's committed hours and divide by the hours theoretically available. Do that three or four times and you have a number that is about your team rather than about optimism.
Capacity is not a target
A sprint filled to 100% of calculated capacity has no room for the surprise that always arrives, and it will fail on the first one. The calculated figure is a ceiling, not a goal, and the gap between it and what a team commits to is where reliability comes from.
Why points and hours should not be mixed
Story points work because they are relative and local: this is about twice that. That property survives a team member being faster or slower, having a bad week, or being new to the codebase.
Convert points to hours and you have thrown all of that 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, use points and forecast from throughput. Doing both at once gets the disadvantages of each.