Sprint Capacity Calculator

Calculate your team's realistic sprint capacity accounting for meetings, PTO, holidays, and historical velocity. Plan sprints accurately with data-driven estimates.

How to Calculate Sprint Capacity

  1. 1

    Add your team members

    Enter each team member's name, role, and daily available hours. Part-time contributors should list their actual working hours rather than a full day. Include everyone who will commit work during the sprint, from developers to QA engineers.
  2. 2

    Configure the sprint duration

    Set the sprint length in working days and choose which days of the week your team works. A standard two-week sprint has ten working days, but you can adjust this to match your organization's cadence.
  3. 3

    Enter adjustments for meetings, holidays, and PTO

    Specify the percentage of each day lost to recurring meetings such as standups, sprint reviews, and retrospectives. Then add any public holidays that fall within the sprint window and log planned time off for individual team members.
  4. 4

    Review capacity results and plan accordingly

    The calculator subtracts all deductions from raw hours and converts the remaining time into recommended story points. Compare these numbers with your historical velocity to commit to a realistic amount of work for the sprint.

Who Benefits from Sprint Capacity Planning

1

Scrum Masters Running Sprint Planning

Scrum masters can present objective capacity data during sprint planning meetings, replacing gut-feel estimates with concrete numbers. This reduces friction when the team needs to push back on an overloaded backlog.
2

Engineering Managers Forecasting Delivery

Managers responsible for roadmap commitments can use capacity calculations across multiple sprints to forecast feature delivery dates and communicate realistic timelines to stakeholders.
3

Remote and Distributed Teams

Teams spread across time zones and countries face overlapping holidays and varied schedules. The calculator consolidates everyone's availability into a single source of truth, preventing last-minute capacity surprises.
4

New Agile Teams Establishing Velocity

Teams that have recently adopted Scrum lack historical velocity data. Starting with capacity-based planning gives them a data-driven baseline until enough sprint history accumulates for velocity-based forecasting.

Why use Sprint Capacity Calculator?

Planning sprints without understanding your team's actual capacity leads to overcommitment, burnout, and missed deadlines. This calculator helps you account for real-world factors like meetings, holidays, and PTO to set realistic sprint goals that your team can actually achieve.

Sprint capacity planning is the foundation of reliable agile delivery. Without a clear picture of how many productive hours your team actually has, sprint commitments become guesswork. This Sprint Capacity Calculator turns guesswork into a repeatable process by computing net available hours from raw team availability, subtracting meeting overhead, public holidays, and individual PTO. The result is a realistic hour budget you can convert into story points using your own hours-per-point ratio.

Accurate capacity data improves every downstream decision. Product owners can prioritize the backlog knowing exactly how much work fits into the sprint. Scrum masters can facilitate planning sessions with objective numbers instead of negotiation. Developers avoid the burnout that comes from consistently overcommitting. If your team also tracks historical velocity, the calculator cross-references past performance with current availability so you can spot trends and adjust before problems surface. Pair it with the Story Point Poker tool for collaborative estimation or the Scope Creep Tracker to monitor mid-sprint changes that erode planned capacity.

Whether you run one-week iterations or month-long sprints, capacity planning scales to any cadence. Enter your team once, save it as a preset, and recalculate each sprint in seconds. Export the results as PDF or PNG to attach to sprint planning documents or share with stakeholders who need visibility into the team's workload. For broader project management, the Dev Request Prioritizer helps you decide which items deserve the capacity you have, and the Retro Meeting board captures lessons learned that feed back into better future planning.

How It Compares

Spreadsheet-based capacity planning is the most common alternative to a dedicated calculator. While spreadsheets offer flexibility, they require manual formula maintenance, are prone to copy-paste errors when team composition changes, and rarely get updated sprint over sprint. Dedicated project management platforms like Jira and Azure DevOps include capacity features, but they are locked behind paid plans and require the entire team to adopt the platform. This calculator sits in between: it is purpose-built for the single task of sprint capacity estimation, runs entirely in your browser with no account required, and produces results in seconds rather than minutes of spreadsheet wrangling.

Compared to mental math or informal planning, a structured calculator eliminates the optimism bias that plagues most sprint commitments. Studies consistently show that teams overestimate available time by 20-30% when they skip formal capacity analysis. By forcing you to enter concrete numbers for meetings, holidays, and PTO, the tool surfaces hidden time sinks that intuition overlooks. The exportable breakdown also creates an audit trail, making it easy to review why a sprint went over or under capacity after the fact.

Sprint Capacity Planning Tips

1
Keep meeting overhead between 15% and 25% for a two-week sprint; anything higher signals too many ceremonies or ad-hoc meetings eating into development time.
2
Never plan to 100% capacity. Reserve a 10-15% buffer for unplanned work such as production incidents, code reviews, and technical support requests.
3
Track completed story points after each sprint and feed that data back into the historical velocity section to improve future estimates over time.
4
Account for onboarding drag when new team members join. Their first two or three sprints typically produce 40-60% of an experienced member's output.
5
Review capacity at the start of every sprint, not just once a quarter. Holiday calendars, PTO requests, and team composition change frequently enough to invalidate old numbers.

Frequently Asked Questions

1

How is sprint capacity calculated?

We start with raw hours (team members multiplied by hours per day multiplied by working days), then subtract meeting overhead percentage, holidays, and individual PTO. This gives you the true available hours for development work.
2

What's a good hours-per-story-point ratio?

Industry averages range from 4-8 hours per story point. Start with 6 hours per point and adjust based on your team's historical velocity. Track actual completion to refine your estimate over successive sprints.
3

Should I include all meetings in the overhead?

Include recurring meetings like standups, sprint planning, reviews, and retrospectives. For a typical 2-week sprint, 15-25% meeting overhead is common. Do not include one-off meetings in the percentage; account for those as individual PTO or time-off entries instead.
4

How do I account for part-time team members?

Set their hours per day to their actual availability. For example, a half-time developer would have 4 hours per day instead of 8. The calculator handles the rest automatically.
5

What is a good utilization rate for a sprint?

Most healthy agile teams land between 70% and 85% utilization after accounting for meetings, holidays, and PTO. If your rate drops below 60%, investigate whether too many ceremonies or excessive context switching are consuming productive hours.

Rate This Tool

0/1000

Get Weekly Tools

Suggest a Tool