Agile Sprint Capacity Planner
Sprint Details
Sprint Length
weeks
Team Size
People
Time Not Coding
Agile Ceremonies and Meetings
hours per person
Total Team Time Off
days
Efficiency
Focus Factor Deep Work
percent
Sprint Availability
Net Available Hours
0
Estimated Story Points
0
Assuming 1 Story Point equals roughly 8 hours of work

What is Agile Sprint Capacity Planning

In software development committing to the right amount of work during sprint planning is critical for team morale and project success. Overcommitting leads to burnout and missed deadlines while undercommitting results in idle time and delayed feature releases.

A Sprint Capacity Planner removes the guesswork from this process. Instead of blindly looking at past velocity capacity planning calculates exactly how many hours your development team has available in the upcoming sprint. It mathematically accounts for upcoming holidays planned vacations and mandatory Agile ceremonies to give Product Owners and Scrum Masters a realistic baseline of what can actually be achieved.

Why Capacity is Different from Velocity

A common mistake in Scrum is confusing capacity with velocity. Velocity is a historical metric. It simply tells you how many Story Points the team successfully completed in previous sprints. If your team averaged 40 points over the last three sprints your velocity is 40.

Capacity on the other hand is a forward looking metric. It tells you how much time your team actually has to work in the upcoming sprint. If two developers are taking a week off for holidays your historical velocity of 40 points is irrelevant because the team does not have the capacity to deliver that much. By calculating capacity first you can adjust your expectations and pull the correct amount of work from the product backlog into the sprint backlog.

The Danger of the 100 Percent Utilization Myth

Many managers mistakenly assume that an 8 hour workday equals 8 hours of productive coding. In reality aiming for full utilization destroys productivity. Software development is complex knowledge work. When developers are booked to full capacity any minor bug unplanned server issue or extended meeting causes a cascading delay across the entire sprint.

Using a Focus Factor usually around 70 to 80 percent builds a necessary buffer into your planning. This accounts for context switching answering quick questions from colleagues code reviews and the natural fatigue that occurs during a workday. Protecting this buffer ensures higher quality code and a more sustainable pace for the engineering team.

Frequently Asked Questions

How do I calculate Agile Ceremonies per person
You need to sum up all recurring mandatory meetings that take developers away from their keyboards. For a standard two week sprint a typical breakdown looks like this. Sprint Planning takes 2 hours Daily Standups take 2.5 hours Backlog Refinement takes 2 hours Sprint Review takes 1 hour and the Sprint Retrospective takes 1.5 hours. This usually totals roughly 9 to 10 hours of fixed meeting time per team member.
What is the Focus Factor and what should I set it to
The Focus Factor represents the percentage of time a developer is engaged in deep uninterrupted work on sprint tasks. Even after deducting official meetings no one codes for 8 hours straight. Reading emails answering chat messages quick code reviews and short breaks take up time. A realistic focus factor for a healthy software team is between 70 and 80 percent. Setting it higher will inevitably lead to failed sprints.
How is the final Net Available Hours calculated
We start with the total gross hours which is the Team Size multiplied by the number of workdays in the sprint multiplied by an 8 hour workday. Next we subtract the total hours lost to vacation public holidays or sick leave. Then we subtract the total hours spent in Agile ceremonies. Finally we multiply that remaining number by the Focus Factor percentage to give you the pure uninterrupted hours available for actual task execution.