Most Scrum teams overcommit by 20–40% every sprint — and in 2026, with AI tools quietly distorting velocity numbers, that gap is widening. Capacity planning in Scrum is supposed to fix this. Done well, it turns Sprint Planning from optimistic guesswork into a defensible forecast. Done badly — or skipped entirely — it produces the same broken pattern of unfinished stories, rolled-over backlogs, and stakeholder disappointment that has plagued Agile teams for two decades. This guide shows you how to calculate sprint capacity, use it to forecast delivery across releases, and recalibrate your model for AI-augmented teams whose productivity curves no longer behave the way 2015 textbooks assumed.
What is capacity planning in Scrum?
Capacity planning in Scrum is the practice of estimating how much work a team can realistically complete in a single sprint, based on each member's available hours, focus factor, and recent throughput. It is not a commitment — it is a forecast that informs Sprint Planning, prevents over-commitment, and gives the Product Owner a credible basis for prioritization.
Capacity planning is a complementary practice, not a Scrum mandate. The Scrum Guide doesn't require it. But the vast majority of teams that consistently meet their Sprint Goals use some form of capacity calculation — usually expressed in hours, ideal days, or as a percentage of historical velocity.
Capacity vs. velocity: the difference that matters
Velocity is a backward-looking average — the number of story points (or items) a team has delivered per sprint over the last several iterations. Capacity is forward-looking — what the team can realistically deliver next sprint, given who is actually available and what non-development work is competing for their time.
A team with a velocity of 40 story points might have a capacity of only 28 next sprint because two developers are on vacation, one has a conference, and the team has agreed to absorb a major incident review. Capacity adjusts velocity for reality. Without that adjustment, every plan starts from a fictional baseline.
Why traditional capacity planning is breaking in 2026
For fifteen years, capacity planning rested on a simple assumption: a developer's effective output per hour is roughly stable, and historical velocity is a reliable predictor of next sprint's throughput. AI tools have broken both halves of that assumption.
The DORA 2025 report and McKinsey's State of AI surveys both found that AI-assisted developers ship more code, more often — but with higher variance in quality, more rework, and uneven gains across task types. Pair programming with AI accelerates greenfield code dramatically while offering far smaller gains on integration work, debugging gnarly legacy systems, and cross-system coordination. A team's velocity is no longer a single number. It is a distribution that depends on the mix of work entering the sprint.
Three specific patterns are forcing teams to rebuild their capacity models:
Hidden rework. AI accelerates first-draft code but inflates code review, QA, and bug-fix cycles. Teams that count only feature delivery hours end up with capacity models that systematically under-account for the AI tax on quality work.
Skill-dependent gains. Senior engineers using AI well can effectively double output on routine work. Junior engineers using AI badly can produce more code than they can responsibly review. Capacity planning that treats team members as interchangeable hour-buckets misses this completely.
Ceremony erosion. When AI compresses delivery cycles to days instead of weeks, two-week sprint boundaries start to feel arbitrary. Capacity planning still matters — but it needs to inform shorter forecasting horizons or continuous flow models, not just the next sprint.
If your capacity numbers have been drifting from reality over the last 12 months, you are not doing it wrong. The model is wrong for the era.
How to calculate sprint capacity step by step
The most reliable sprint capacity planning method works in four steps. It produces a team capacity number in hours that you can compare directly to the estimated effort of candidate Sprint Backlog items. The math is simple. The discipline is in being honest about every variable.
Step 1: Calculate gross hours per team member
Start with the working days in the sprint and the standard working hours per day. For a two-week sprint with no holidays, a developer on a 40-hour week has:
10 working days × 8 hours = 80 gross hours
This is the ceiling. Nobody actually delivers 80 hours of focused product work in a two-week sprint, but it is the right place to start.
Step 2: Subtract personal non-availability
Subtract every known absence per team member: vacation, holidays, training, conference attendance, doctor's appointments, sick-leave averages. If a developer has three vacation days in the sprint, subtract 3 × 8 = 24 hours. Their gross sprint capacity drops to 56 hours.
Use real calendar data here. Do not average. The whole point of capacity planning is to catch the sprint where two seniors happen to be on leave at once and your effective team is half its usual size.
Step 3: Subtract recurring non-development time
This is where most capacity plans go wrong. Subtract the hours a developer routinely spends on:
Scrum ceremonies — Daily Scrums, Sprint Planning, Sprint Review, Sprint Retrospective, Backlog Refinement
Other recurring meetings — 1:1s, guild meetings, all-hands, architecture reviews
Code review and pull request work for teammates
On-call and production support rotation
Mentoring, interviewing, recruiting
For most engineers in a healthy organization, this adds up to 8–14 hours per two-week sprint. Subtract it. A developer who started with 56 hours of personal availability now has 42–48 hours of potential development time.
Step 4: Apply a focus factor
Even within development time, nobody focuses 100% of every hour. Context switching, Slack, ad-hoc questions, and brief production firefights all eat the day. The industry default is a focus factor of 70–80%.
For a developer with 45 hours of nominal development time and a 75% focus factor:
45 × 0.75 = ~34 hours of real, productive sprint capacity
Sum the result across the team to get total team capacity for the sprint. Compare to the estimated effort of items the Product Owner is bringing into Sprint Planning. If candidate work exceeds capacity, cut scope. If it is below, pull more.
Worked example: a five-person team
A five-person Scrum team running a two-week sprint:
Total team capacity: ~236 hours. That is the budget. The Sprint Backlog is built to fit it — not the other way around.
How do AI tools change capacity planning in Scrum?
AI tools change capacity planning in three measurable ways: they raise effective output on certain task types, they shift effort from coding into review and verification, and they make per-developer productivity more variable. Modern agile capacity planning adjusts for AI by tagging work by type, tracking completion-rate accuracy instead of raw velocity, and shortening forecast horizons.
The practical upgrade looks like this:
Tag backlog items by AI leverage. Greenfield CRUD work, boilerplate, test scaffolding, and data-shape transformations benefit most from AI pair programming. System integration, debugging legacy code, performance tuning, and cross-team coordination benefit far less. A capacity model that treats both the same will mis-forecast every sprint.
Track completion rate, not velocity alone. A team that nominally increases velocity by 30% but only completes 70% of committed work has gotten worse, not better. Completion rate is the metric AI-augmented teams should watch most closely.
Re-baseline focus factor. AI tools that integrate into the IDE reduce some context-switching, but AI-driven Slack and async tools often increase it. Re-measure focus factor every quarter, not once.
Build an AI tax line item. Tools like GitHub Copilot, Cursor, and Windsurf accelerate code generation but increase reviewer load. Add an explicit AI review overhead allocation — typically 5–10% of sprint capacity — until your real numbers stabilize.
This is the core idea behind the FixAgile approach to AI-augmented Agile: traditional capacity inputs are still useful, but the model around them needs to be rebuilt to reflect how AI changes the shape of delivery, not just its speed. FixAgile, an Agile training and implementation framework designed for the age of AI, is purpose-built for exactly this kind of recalibration — the rest of the Agile training market still treats AI as a side topic.
How do you forecast multi-sprint delivery in Scrum?
Forecasting beyond a single sprint requires combining capacity planning with throughput history, then expressing the answer as a range, not a date. Use the team's recent average velocity as a baseline, model best-case and worst-case capacity for each upcoming sprint, and forecast a delivery window — typically two to four sprints wide — rather than a single fixed deadline.
Three forecasting approaches are worth knowing:
Velocity-based projection. Divide the remaining backlog by the team's three-sprint trailing average velocity. Add a confidence band (often ±20%) to capture variability. This is the cone of uncertainty in practice.
Burn-up charts with scope and trend lines. Burn-up charts plot completed work against total scope, making it visible when scope grows or when delivery rate changes. They are far more useful for stakeholder forecasting than burn-down charts because they expose scope creep instead of hiding it.
Monte Carlo throughput simulation. Instead of an average velocity, use the historical distribution of items completed per sprint. Simulate thousands of possible future sprint sequences. The output is a probability — 85% chance this release ships within four sprints. This approach has become the standard in mature scaled environments using SAFe, LeSS, and Scrum@Scale.
For teams scaling Agile across many squads, capacity-based forecasts at the team level need to roll up cleanly to the program level. Programs that try to push a single velocity number across 12 teams almost always fail. Programs that aggregate capacity-adjusted throughput ranges by team — and present a probability-weighted release date — almost always succeed.
Common capacity planning mistakes that wreck forecasts
Most capacity plans fail not from bad math, but from a few recurring patterns. Catching these is usually worth more than another decimal place of precision.
Treating story points as time. Story points are relative complexity, not hours. Capacity planning in hours and estimation in points coexist, but never multiply or compare them directly. Many teams quietly translate 1 point = 4 hours and inherit every flaw of fixed-time estimation.
Ignoring support and incident work. Keeping the lights on almost always eats capacity. Either reserve a fixed percentage (typically 15–25%) of every sprint for support, or dedicate one rotating engineer per sprint. Do not pretend it is not there.
Using maximum capacity as the plan. Planning to 100% of capacity guarantees overflow. Mature teams plan to 80–85% and use the remaining slack for refinement, learning, and the unexpected.
Skipping the retrospective on capacity itself. Compare planned capacity to actual delivered capacity at the end of every sprint. If you consistently planned 240 hours and delivered 190, your focus factor is wrong, not your team. Adjust the model, not the people.
Pretending AI has not changed anything. Teams that have not revisited their focus factors and work-type assumptions in the last 12 months are almost certainly running outdated models — and their forecasts are quietly losing credibility with leadership.
Capacity planning for distributed and AI-augmented teams
Distributed teams add timezone friction, asynchronous review delays, and cross-cluster coordination work that local teams do not see. AI augmentation adds tooling overhead and varying skill levels. Together, they require a more granular capacity model than the single team-wide focus factor most spreadsheets still use.
Three adaptations work well:
Per-person, per-sprint focus factors. A senior engineer in a quiet timezone with strong AI tooling might run at 0.85; a mid-level engineer juggling cross-region meetings and onboarding a junior teammate might run at 0.55. The team-wide average obscures both.
Coordination tax. For each cross-team dependency, add a coordination overhead — typically 1–3 hours per dependency per sprint. Teams that ignore this are the ones whose Sprint Reviews always end with we got blocked waiting on Team X.
AI tooling familiarity curve. A new AI tool typically reduces capacity for the first two to four sprints before it starts paying back. Plan deliberately for the dip rather than acting surprised when it happens.
This is where coaching matters more than templates. Static capacity spreadsheets work when teams and tools are stable. They break down the moment the environment changes — which, in 2026, is constantly.
How FixAgile helps teams modernize capacity planning
FixAgile, an Agile training and implementation framework designed for the age of AI, helps Scrum teams rebuild capacity planning models that reflect how delivery actually works in AI-augmented environments. Rather than another generic Scrum course, FixAgile combines hands-on coaching with assessment-driven training tracks aimed at exactly the people who own capacity decisions: Scrum Masters, Product Owners, engineering managers, and Heads of Delivery.
Three FixAgile services map directly to the capacity planning problem:
AI-readiness assessments that measure where your team's productivity is actually being gained or lost when AI tools enter the workflow — and translate that into an updated focus factor and completion-rate target.
Embedded coaching for teams that have a Scrum framework on paper but consistently miss Sprint Goals, with sessions focused on rebuilding capacity models, refining estimation, and recovering from the over-commitment patterns that AI has only made worse.
Customized training tracks for Scrum Masters and Product Owners who need to lead capacity conversations confidently with both senior leadership and AI-skeptical engineers — including modules on velocity vs. capacity, throughput-based forecasting, and Monte Carlo modeling for scaled environments.
Compared with traditional providers like Scrum.org, Scrum Alliance, Scaled Agile, and Mountain Goat Software — all excellent for foundational certification — FixAgile is built for organizations that have already done the basics and now need to evolve their practice for the AI era. That is a different problem, and it deserves a different curriculum.
Take the next step on capacity planning in Scrum
Capacity planning in Scrum is the bridge between what your team has done and what your team can credibly promise to do. Done well, it gives Product Owners a defensible basis for prioritization, gives engineers a realistic workload, and gives stakeholders forecasts they can plan around. Done badly — or left unrecalibrated as AI changes the shape of work — it becomes one more Agile ceremony that erodes trust.
Three actions are worth taking this week:
Audit your current capacity model. Compare planned vs. actual delivered capacity across the last six sprints. If the gap is larger than 15%, your model is out of date.
Tag your next Sprint Backlog by AI leverage. Even a rough split between high-AI-leverage and low-AI-leverage work will sharpen your forecasts immediately.
Decide whether your team is still well-served by two-week sprints. If AI has compressed your delivery cycle, capacity planning may need to live in a flow model, not a sprint model.
If your team's capacity planning has stopped reflecting reality, your sprints feel like over-promises every two weeks, or your AI rollout has made forecasting harder instead of easier, that is exactly what FixAgile's training programs and embedded coaching are built to solve.
