Sprint Capacity Planning: How to Calculate Capacity and Stop Overcommitting
Most sprint failures aren't caused by a lack of effort — they're caused by committing to more work than your team actually has time to do. Here's how to fix that with a simple formula and a free calculator.
It's Wednesday of sprint week. You planned 42 story points. The team has delivered 18. Two engineers are blocked. One is on an unexpected sick day. And the sprint review is Friday.
Sound familiar? This isn't a productivity problem. It's a capacity planning problem. The sprint was overcommitted before it even started — and nobody knew it because the planning process ignored real-world availability.
This guide walks you through exactly how to calculate sprint capacity correctly, the formula every Scrum Master should know, and how to use a free sprint capacity calculator to make the math instant.
What Is Sprint Capacity?
Sprint capacity is the total amount of work your team can realistically complete in a sprint, measured in hours or story points, after accounting for:
- Sprint duration (number of working days)
- Team size and individual daily availability
- Planned leaves, public holidays, and days off
- Overhead (standups, code reviews, meetings, admin) via a focus factor
Capacity is not the same as velocity. Velocity is a trailing average of work completed in past sprints — useful for forecasting over time. Capacity is a forward-looking, sprint-specific calculation of what your team can actually do this sprint.
"Velocity tells you where you've been. Capacity tells you where you can go."
The Sprint Capacity Formula
For each team member:
Net Hours = (Sprint Days − Days Off) × Daily Hours × Focus Factor Then sum Net Hours across all team members to get Total Team Capacity.
To convert to story points:
Story Points = Total Net Hours ÷ Hours per Story Point Example Calculation
Let's say you have a 2-week sprint (10 working days) with 4 developers:
- Dev A: 10 days available, 8 hrs/day, 70% focus → (10 − 0) × 8 × 0.70 = 56 hrs
- Dev B: 10 days available, 8 hrs/day, 70% focus → 10 × 8 × 0.70 = 56 hrs
- Dev C: 8 days (2 days leave), 8 hrs/day, 70% focus → 8 × 8 × 0.70 = 44.8 hrs
- QA D: 9 days (1 public holiday), 8 hrs/day, 65% focus → 9 × 8 × 0.65 = 46.8 hrs
Total Capacity: 203.6 hours
At 6 hours per story point: ~34 story points — not 42. That's a significant gap.
What Is a Focus Factor and What Should Yours Be?
The focus factor (sometimes called the availability factor) represents the percentage of working hours a team member dedicates to actual sprint work versus overhead activities like:
- Daily standups and sprint ceremonies
- Code reviews and PR feedback
- Email, Slack, and ad-hoc meetings
- Unplanned production issues or bug fixes
Most Scrum teams use a focus factor between 60% and 80%. If your team is newer or has heavy meeting culture, start at 65%. If your team is experienced with minimal interruptions, 75–80% is realistic.
Never plan to 100%. A team running at 100% capacity with no buffer always misses — because production incidents, PR reviews, and meetings are not optional.
The 3 Most Common Sprint Capacity Mistakes
1. Ignoring Individual Leaves
Planning to a team average instead of per-person availability is the most common mistake. If two of your five engineers are out for two days each, your capacity drops by 32 hours — roughly 5 story points. That's invisible if you plan from an average.
2. Forgetting Sprint Ceremonies
A 2-week sprint typically has sprint planning (2–4 hrs), daily standups (5 hrs total), backlog refinement (2 hrs), and retrospective (1 hr). That's roughly 10 hours of ceremonies per person — which is why a 70% focus factor is a starting point, not a luxury.
3. Using Last Sprint's Velocity as This Sprint's Capacity
Last sprint your team completed 40 points? Great. But did you check if two engineers who carried 25 of those points are both on leave this sprint? Velocity doesn't adjust for that. Capacity calculation does.
How to Use the Free Sprint Capacity Calculator
Doing this math manually for a team of 6–10 people across a two-week sprint is tedious and error-prone. The Klority Sprint Capacity Calculator does it instantly — no login, no account required.
Here's how to use it in under 2 minutes:
- Set your sprint duration — enter the start and end dates or the number of working days.
- Add each team member — name, daily availability (hours), and days off during the sprint.
- Set the focus factor — start at 70% if you're unsure.
- Enter your hours-per-point ratio — or leave the default (6 hrs/point).
- Get your results — total net hours per person, total team capacity, and recommended story points.
The calculator gives you a number you can trust before you ever open your backlog for planning. Try it free at klority.com/tools/sprint-capacity-calculator.
Beyond the Calculator: Capacity Planning Inside Your Workflow
A standalone calculator is a great start — but it lives outside your project management tool. Every sprint, you're manually re-entering data, cross-checking with your Jira board, and hoping nothing slips through.
Klority's built-in capacity planning brings this directly into your sprint workflow:
- Workload visibility per engineer — see task distribution and assignment load across your team as you plan
- Sprint-level availability tracking — log and manage team member time-off within your sprint context
- Capacity-aware planning — pull work from your backlog with awareness of team bandwidth, not just historical velocity
- Sprint metrics — track progress and team output so planning improves sprint over sprint
This is part of why teams switch to Klority from Jira — not just for cost savings (see our pricing page for the comparison), but because Jira doesn't show you when your sprint is already overcommitted at planning time.
Capacity Planning Checklist for Every Sprint
- ✅ List all team members and confirm sprint availability
- ✅ Check for public holidays in the sprint window
- ✅ Log planned leaves per person before capacity calculation
- ✅ Apply an honest focus factor (start at 70%)
- ✅ Run the capacity formula or use the free calculator
- ✅ Pull from the backlog to match capacity, not the other way around
- ✅ Leave a 10–15% buffer for unplanned work
Conclusion
Overcommitted sprints aren't a team discipline problem — they're a planning information problem. When you calculate capacity per person, account for leaves and ceremonies, and apply a realistic focus factor, you stop planning to an imaginary team and start planning to the team you actually have.
Start with the free sprint capacity calculator for your next sprint. It takes two minutes and will give you a more honest number than any velocity trend ever will.
Want capacity planning built directly into your sprint workflow — without the manual spreadsheet? Try Klority free and see how workload indicators and leave-aware planning make every sprint more predictable.
Shanmuganathan P
Founder, Klority"Shanmuganathan is the founder of Klority, building the unified engineering workspace for teams who are done paying for Jira, Confluence, and TestRail separately."