Sprint Capacity Planner
Work out what a sprint can actually hold. Set the sprint length, the team, and each person's holidays, ceremonies and focus factor. The page returns total person-hours, person-days, and a forecast in story points with a confidence band, so the commitment matches the capacity rather than the optimism in the room.
Explain like I'm 5 (what even is this calculator?)
Pick a sprint length. Add the team. Tell the page who is off, who has lots of meetings, and how focused everyone usually is. The page does the arithmetic that planning meetings keep getting wrong: it subtracts the holidays, trims for ceremonies, applies the focus factor, then converts the hours into story points using your team's velocity. The number that falls out is roughly what the team can finish without burning out by Thursday week two.
Plan the sprint
Results
- Total available capacity 0 person-hours
- In person-days 0 person-days
- Forecast story points 0 story points
- Confidence band 0 to 0 story points
Per-person breakdown
| Name | Holiday | Ceremonies | Focus | Hours | Days | Points |
|---|
Prove it
Every figure on this page comes out of the same chain of arithmetic. No black box. If the workings below do not match what you can do on the back of an envelope, the page is wrong, not your envelope.
Per person
- Working days = sprint days minus holiday days (clamped at zero, you cannot owe the company holidays).
- Raw hours = working days x hours per day.
- After focus = raw hours x focus factor (0 to 1).
- After ceremonies = after-focus x (1 minus ceremonies percent / 100). This is the person-hours figure.
- Person-days = person-hours / hours per day.
- Story points = person-days x velocity.
Team
- Total hours = sum of every person's hours.
- Total days = total hours / hours per day.
- Forecast points = total days x velocity.
- Confidence band = forecast x (1 plus or minus the band percent).
Workings used in this calculation
Useful? Save this calculator: press Ctrl + D to bookmark it.
Why sprint capacity planning is worth half an hour up front
Most teams plan sprints by feel. The product owner brings a stack of stories to planning, the team chews through them, somebody says "yeah, that feels about right", and a number gets written on a card. Two days in, somebody is on holiday nobody remembered, the design review meeting nobody flagged ate four hours, and the sprint goal quietly slips out the window. Spending half an hour on a capacity calculation up front, with the actual people in the room, prevents about eighty per cent of that. It will not stop unexpected production incidents, but it will stop you committing to a sprint that was never mathematically possible.
What the focus factor really represents
The focus factor is the honest gap between the time someone is at work and the time they spend moving sprint stories forward. The other hours go to onboarding a new starter, reviewing a colleague's pull request, answering Slack, helping support diagnose a customer issue, fixing the build, taking a call with sales, or recovering from any of the above. None of that is wasted, all of it is necessary, but very little of it lands on the sprint board. A team starting out with shaky engineering practices and a lot of operational load might run at 50% to 60%. A mature team with good test coverage, a stable platform, and clear separation between sprint work and unplanned interruptions can hold 75% to 80%. Anything above that is either short-lived heroism or a team about to burn out, and neither belongs in a planning forecast.
Common ways this calculation goes wrong
The single most common error is forgetting holidays. A two-week sprint where one person is off for three days has lost six per cent of total capacity before you even start. Plug it in and watch what falls out. The second most common error is undercounting ceremonies. Stand-up plus planning plus review plus retro plus refinement plus the design review nobody calls a ceremony but everyone has to attend is comfortably 15% in many teams, not the 10% they like to claim. The third is overestimating velocity, particularly after a strong sprint. Velocity is a noisy three-sprint average, not the best single sprint you ever had. If your last three sprints delivered 18, 24 and 21 points against 100 person-days available, your velocity is 0.21, not 0.24.
The fourth error is treating the forecast as a commitment. The output of this page is a planning input, not a contract. Use the lower bound of the confidence band as the realistic commit, the midpoint as the stretch, and the upper bound as the "everything went brilliantly" outcome. Stakeholders trying to lock you to the upper bound are asking for the project equivalent of a mortgage payment that assumes a pay rise.
Edge cases worth knowing
If a person's holidays are equal to or greater than the sprint length, the page clamps their working days at zero rather than going negative. They contribute no hours to the sprint, which is the right answer. A focus factor of 100% means the person spends every working hour on sprint stories, which is fine to model as an upper bound but rarely matches reality. A ceremonies figure of 0% says the team has no ceremonies at all, which is unusual unless you have just dropped the lot. Velocity of 0 returns 0 forecast points, which is occasionally useful for working out raw capacity in hours alone.
How to use the output in a real planning session
Open the page, fill in the team, and project the per-person breakdown on the screen everyone can see. The conversation tends to shift from "how much do you think we can do" to "Bel is off Thursday and Friday, so the realistic figure is the lower bound, what stories do we cut?" That is a more useful conversation. The prove-it panel is there for the inevitable senior leader who wants to know where the number came from: open it, walk through the working, and the suspicion that the team is sandbagging tends to evaporate when they can see the arithmetic.
Related calculators
Capacity is one half of the plan. These cover the rest.
Frequently asked questions
What focus factor should I use?
Most teams land between 60% and 80%. The focus factor is the share of a working day that turns into actual delivery once you account for context-switching, support, code review, and the small interruptions that never make it onto the sprint board. New teams or teams with heavy operational load tend to be lower (50% to 60%); steady, mature teams with good engineering practice can push 75% to 80%. Anything above that is usually wishful thinking dressed up as planning.
What does the velocity figure mean here?
Story points per person per day. The default of 0.6 says one developer can typically clear about 0.6 story points of work in a normal working day. Take your team's last three completed sprints, divide story points delivered by total person-days available in those sprints, and use that figure. Velocity is team-specific. There is no industry benchmark, and trying to compare points across teams is one of the great wastes of management time.
Why is the default sprint 10 days?
Two-week sprints are the most common pattern, which is ten working days. If you run weekly sprints, set it to five. For three-week or four-week iterations, set fifteen or twenty. The maths scales linearly, so a longer sprint with the same team and the same focus factor returns proportionally more capacity.
Why is there a confidence band on the forecast?
Because point estimates lie. A single number like "24 story points" suggests precision the planning process does not have. The ±20% band is a defensible default: it acknowledges that velocity wobbles sprint to sprint, and that two people off sick at the same time can knock a chunk out of capacity nobody saw coming. Plan to the lower bound, stretch into the upper if everything goes well.
Should ceremonies be a percentage or a fixed time?
A percentage scales naturally with sprint length, so it works whether you run a one-week or four-week iteration. As a rough guide: 10% covers the standard daily stand-up, planning, review and retro for a typical two-week sprint. 15% to 20% is more honest if your team also has a refinement session, design reviews, or a weekly all-hands. If your ceremonies regularly creep above 25%, the meeting load is the bigger problem, not the capacity calculation.