Agile Sprint Capacity Calculator — Free Tool for IT Project Managers

If you’ve ever committed to a sprint and then watched it fall apart by day three, the problem usually isn’t the team — it’s that the capacity number going into planning wasn’t realistic. This sprint capacity calculator gives you an adjusted figure in under a minute, accounting for PTO, ceremony overhead, and your bug/interrupt buffer before you pull a single story.

No account, no email, no export fees. Just enter your team numbers and get a defensible capacity estimate you can paste directly into your planning doc.

How Sprint Capacity Is Calculated

The Sprint Capacity Calculator uses a four-step formula that mirrors how most experienced Scrum Masters run planning math manually:

• Gross capacity — team size × sprint days × focus hours per day. Focus hours (not clock hours) is the key input here; 6 hours is the realistic number for most knowledge workers once you strip out context-switching and admin.
• Absence deduction — planned PTO and holidays removed in full-day equivalents.
• Ceremony overhead — planning, review, retro, and grooming hours multiplied by team size. Consistently underestimated — on a two-week sprint it can eat 8–12 hours per person.
• Bug and interrupt buffer — a percentage of net hours reserved for unplanned work. 15–20% is standard for a mature team; higher if you’re supporting production.

Story Points vs. Hours: How the Recommendation Works

If you enter a historical velocity, the tool scales your story point recommendation proportionally to your capacity change. If your usual 10-person team is running at 70% capacity this sprint, your point target scales down accordingly rather than staying at the full velocity number. If you’re a new team with no history, it uses a 5-hours-per-point heuristic as a starting calibration point.

Sprint Capacity Calculator: Common Mistakes This Catches

• Using headcount as capacity. 8 people × 10 days is not 80 person-days of dev output. Ceremonies and support load reduce that fast.
• Ignoring partial absences. A half-day of PTO still disrupts flow for the surrounding hours. Model it.
• Zero buffer for unplanned work. Production incidents, clarification threads, and PR review cycles eat capacity. If you aren’t budgeting for it, you’re overcounting.
• Planning to velocity instead of capacity. Velocity is an average at full capacity. If this sprint has 80% capacity, your point target should reflect that.

For a broader look at how AI tools are changing IT project management, see the 7 best AI tools for IT professionals and PMs in 2026. The agile project management overview covers the methodology context if you’re newer to sprints.

Please support our platforms hee at my Dot,Cards platform clicking here ir relly helps support the site

Frequently Asked Questions About Sprint Capacity Planning

What is sprint capacity and how is it different from velocity?

Sprint capacity is the total amount of work your team can realistically take on in a given sprint, measured in hours or story points, after accounting for absences, ceremonies, and interrupt work. Velocity is a historical average of how many story points your team has completed across past sprints at full capacity. The two are related but not the same — if this sprint has 80% of your usual capacity due to PTO, your sprint capacity is lower, but your historical velocity hasn’t changed. A good sprint capacity calculator adjusts your point commitment to match your actual available hours, not your best-case average.

How many story points should a team complete per sprint?

There’s no universal number — it depends entirely on your team size, sprint length, and how your team calibrates story points. A common starting heuristic for a new team is roughly 5 hours of focused work per story point, so a 5-person team with 6 focus hours per day over a 10-day sprint has around 300 gross hours, which translates to roughly 40–50 points at that calibration. Once you have 3–5 sprints of data, use your actual velocity instead of the heuristic. The most important thing is internal consistency — your story point scale only needs to make sense within your own team.

What percentage of sprint capacity should be reserved for bugs and unplanned work?

The standard guidance is 15–20% for a mature product team. New teams or teams supporting an active production system often need 25–30% because the interrupt rate is higher and harder to predict. If you’re consistently burning through your buffer and pulling stories to the next sprint, increase the percentage rather than pressuring the team to absorb the overrun. Tracking actual interrupt hours over a few sprints gives you a data-backed buffer percentage specific to your context, which is more accurate than any rule of thumb.

Should ceremony time count against sprint capacity?

Yes — and most teams underestimate how much ceremony eats into delivery time. On a standard two-week sprint, sprint planning (2h), daily standups (10 × 15min = 2.5h), sprint review (1h), retrospective (1h), and backlog grooming (1–2h) add up to 7–8.5 hours per person. On a 5-person team, that’s 35–42 person-hours per sprint that aren’t available for story work. Leaving ceremony time out of your sprint capacity calculator is one of the most common reasons teams consistently miss their sprint goals.