Sprint Capacity Calculator
Work out how many hours your team really has next sprint, after time off and overhead, and turn that into a realistic story point commitment.
| Team member | Days off | Hours / day | Available days | Focused hours |
|---|---|---|---|---|
| 10 | 42 | |||
| 9 | 37.8 | |||
| 10 | 42 | |||
| 8 | 33.6 |
Available days × hours per day, summed for the team.
Raw capacity × 70% focus factor.
Last velocity scaled by this sprint's capacity versus last sprint's.
What is sprint capacity?
Sprint capacity is the amount of time a team actually has available for sprint backlog work in a given sprint. It differs from sprint to sprint because of public holidays, leave, training, on-call duty and people joining or leaving the team. Velocity tells you what the team usually delivers; capacity tells you whether this particular sprint is a usual one. Using both together is the most reliable way to avoid over-committing.
How the calculation works
The focus factor is the honest part of the calculation. Nobody spends eight hours a day on backlog items: stand-ups, planning, refinement, code reviews, support questions and context switching all take time. A focus factor of 70% on a six-hour productive day is a common, realistic starting point.
A worked example
A team of four runs two-week sprints of 10 working days. Developer 2 has one day of leave and the QA engineer has two. Each person plans 6 productive hours a day and the team uses a 70% focus factor.
- Available days: 10 + 9 + 10 + 8 = 37 person-days.
- Raw capacity: 37 × 6 = 222 hours.
- Focused capacity: 222 × 0.70 = 155.4 hours.
- Last sprint the team completed 30 points with 160 focused hours, so this sprint's suggested commitment is 30 × (155.4 ÷ 160) ≈ 29 points.
These are the default values in the calculator, so you can adjust them to match your own team.
Using capacity in sprint planning
Calculate capacity before the planning meeting and share it at the start. The team then pulls items from the top of the refined backlog until the estimated work approaches the capacity, leaving a small buffer for surprises. If the sprint has a clear goal, check that the committed items actually achieve it; a full sprint with no coherent goal is a warning sign. Our sprint planning template has fields for the goal, capacity and committed points side by side.
Tips for more accurate capacity
- Collect time off early. Ask for leave and holidays before planning, not during it.
- Account for on-call and support. Whoever handles production issues this sprint has less time for backlog work.
- Calibrate the focus factor. Compare planned with actual hours for a few sprints and adjust.
- Plan skills, not just hours. Ten hours of developer time does not cover a sprint that is mostly testing.
- Leave slack. Committing to 80 to 90% of capacity absorbs the unexpected without carry-over.
When capacity changes mid-sprint
Plans meet reality: someone falls ill, an urgent production issue appears, or a stakeholder asks for something that cannot wait. When capacity drops mid-sprint, make the trade-off visible rather than quietly working longer hours. The product owner and team agree which lower-priority item comes out of the sprint, the sprint goal is protected where possible, and the change is noted so the next planning session can learn from it. Repeated mid-sprint disruption is a signal to reserve explicit capacity for support work, or to move that work to a separate Kanban flow with its own WIP limit.
Capacity and velocity together
Velocity is a lagging indicator: it tells you what happened. Capacity is a leading indicator: it tells you what is possible next. Track velocity with our sprint velocity calculator, check capacity before every planning session, and your forecasts will be both realistic and explainable to stakeholders.
Capacity planning in Taskmei
Taskmei tracks each member's allocation per project and records velocity at sprint close, so planning starts from real numbers. Scrum masters see team load on the delivery dashboard and can rebalance work before a sprint starts rather than after it slips.
Frequently asked questions
What focus factor should I use?
Many teams start between 60% and 75%. It represents the share of working hours left for sprint backlog work after meetings, reviews, support and context switching. Measure it by comparing planned hours with the hours actually spent on sprint work over a few sprints.
Should I plan capacity in hours or story points?
Both are useful. Hours make the effect of holidays and part-time members visible; story points connect capacity to the team's velocity. This calculator does the hours first and then converts them into a suggested points commitment.
Do Scrum ceremonies count against capacity?
Yes. Sprint planning, daily stand-ups, refinement, reviews and retrospectives all take time. Either subtract them explicitly or account for them through the focus factor, but not both.
How do I handle part-time team members?
Enter their actual hours per day on the team. Someone split 50/50 between two teams might have 3 focused hours a day rather than 6.
Is it okay to commit to more than the calculated capacity?
Occasionally, if the team agrees and the risk is understood. Consistently over-committing leads to carry-over, rushed quality and an unreliable velocity, so it is usually better to commit to slightly less and pull in extra work if the sprint goes well.
Related resources
Plan sprints with real capacity
Taskmei shows team load and allocation before you commit. Free plan for small teams.