How is Sprint Capacity calculated?

The capacity formula is: (Sprint Days - Days Off) x Daily Availability x Focus Factor (%). For example, a developer working 8 hours/day over a 10-day sprint with 1 day off and a 70% focus factor has a net capacity of (10 - 1) x 8 x 0.70 = 50.4 Net Hours.

What is a Focus Factor in Agile?

Focus Factor is the percentage of a team member's working hours dedicated to active, productive sprint work. It accounts for inevitable overhead like daily standups, meetings, email correspondence, administrative work, and minor context switching. Teams typically use a focus factor of 60% to 80%.

Free Agile Resource

Sprint Capacity Calculator

Accurately calculate your Scrum team's capacity in hours and story points. Accounts for holidays, vacations, and meeting overhead to ensure you never over-commit.

Sprint Duration (Days)

days

Hours per Story Point

hours/SP

Total Net Capacity

276.8Hours

Adjusted for team time-off & focus factors.

Suggested Target

34.7Story Points

Based on 8 hours per story point.

Average Team Focus

74%

Recommended: 60% - 80% to absorb overhead.

Team Members (5)

Configure individual working hours and planned vacations.

Teammate & Role	Daily Hours	Days Off	Focus %	Net Capacity	Points
				54h	6.8 SP
				56h	7 SP
				53.2h	6.7 SP
				41.6h	5.2 SP
				72h	9 SP

Data autosaves locally in your browser.

Upgrade Your Agility Workflow

Stop Managing Capacity in Spreadsheets

Klority links team calendars, time-off logs, and historical sprint velocity directly into your active sprints. Zero manual imports, zero formula bugs.

Try Klority Free

What is Sprint Capacity and Why is it Critical?

In Agile and Scrum methodologies, sprint capacity is the actual time-based availability a development team has for sprint work. Unlike velocity (which is a backward-looking metric averaging past work), capacity looks forward to plan the upcoming sprint.

Understanding capacity helps prevent the most common sprint failure modes: over-commitment, developer burnout, and spillover tasks. When you adjust capacity for planned leaves, bank holidays, and meeting overhead, your sprint commitments become realistic and predictable.

The Capacity Calculation Formula

Sprint capacity is calculated individually for each teammate and summed for the total team capacity:

Net Capacity = (Sprint Duration - Days Off) × Daily Work Hours × Focus Factor

Where:

Sprint Duration: The number of actual working days in the sprint (excluding weekends).
Days Off: Individual vacation days, sick leaves, or national holidays during the sprint.
Daily Work Hours: Contracted hours per day (typically 8, or adjusted for part-time members).
Focus Factor: The percentage of time a developer can spend doing core sprint tasks, minus overheads like code reviews, standups, client meetings, and minor breaks.

Frequently Asked Questions

What is the difference between Sprint Velocity and Sprint Capacity?

Velocity measures what the team actually finished in past sprints on average (e.g., 40 Story Points). Capacity calculates how much working time the team has for the upcoming sprint (e.g., 280 hours). Capacity adjusts your velocity commitment: if two team members are on vacation, your capacity is lower, meaning you should pull fewer story points than your average velocity.

What is a realistic Focus Factor for software teams?

Most agile teams operate at a 60% to 80% focus factor (0.6 to 0.8). A 100% focus factor is unrealistic because developers have daily meetings, code reviews, administrative work, support tasks, and general workspace context switching.

How do I convert hours of capacity to Story Points?

To estimate Story Points from net hours, divide the total net hours by your team's historical **Hours per Story Point ratio**. For instance, if your team historically completes 1 story point for every 8 hours of net work, and you have 320 net hours of capacity, your estimated point budget is 40 Story Points (320 / 8).

Free Resources

Jira + TestRail + Confluence in One Hub

Klority is built specifically for small-to-mid engineering teams who want speed without Atlassian-scale complexity. Bring your backlog, testing cycles, and engineering wiki into a single interface.