Sprint Velocity & Capacity Forecast

Sprint velocity and capacity forecast planning uses historical throughput data and team availability to predict future sprint completion, enabling realistic commitment and release forecasting that accounts for variance and avoids the systematic over-commitment common in traditional project planning.

Concept Overview

Velocity is empirical measurement: story points completed per sprint, averaged over 3-6 sprints. Not estimation of what team "should" do, but observation of what they actually accomplish. Example: Team completed 38, 42, 35, 45, 40, 38 points over 6 sprints. Mean velocity: 39.7 ≈ 40. Standard deviation: 3.4. Use for planning: Commit to ~40 points next sprint (or 35-37 for safety buffer).

Capacity adjusts velocity for availability. Normal sprint: 6 people × 10 days = 60 person-days. Upcoming sprint: 1 person on vacation (10 days), company holiday (6 person-days). Available: 60 - 10 - 6 = 44 person-days. Capacity factor: 44/60 = 73%. Adjusted velocity: 40 × 0.73 = 29 points. Commit to 29, not 40. This prevents over-commitment when team is short-staffed.

Forecasting uses velocity range, not single point. 200-point backlog at 40 velocity = 5 sprints (simplistic). Better: 40 ± 8 velocity. Pessimistic: 200/32 = 6.25 sprints. Expected: 200/40 = 5 sprints. Optimistic: 200/48 = 4.2 sprints. Communicate: "5-7 sprints, most likely 5-6." Stakeholders get realistic range, not false precision.

Key Variables & Intuition

• Team Size — Number of developers; velocity scales roughly with size (not linearly—communication overhead)
• Sprint Length — Typically 1-4 weeks; 2 weeks most common (enough time to complete stories, short enough for course correction)
• Avg Velocity — Historical points completed per sprint; primary forecasting input
• Velocity Std Dev — Variance in velocity; lower = more predictable
• Planned PTO — Days off during sprint; reduces available capacity
• Meeting Hours — Non-development time; meetings, ceremonies, reviews reduce capacity
• Backlog Size — Total points to complete; divided by velocity for sprint count

Assumptions

• Past velocity predicts future velocity (team composition, domain, tech stack stable)
• Story point calibration is consistent (teams don't inflate or deflate over time)
• Backlog is sized accurately (estimates don't change significantly during execution)
• Velocity is normally distributed (allows mean ± std dev forecasting)
• Team works at sustainable pace (no crunch that temporarily inflates velocity)

Limitations & Edge Cases

• New teams — No velocity history; use capacity-based planning until 3+ sprints complete
• Major changes — New team members, new technology, new domain resets velocity baseline
• Estimation drift — Teams may unconsciously inflate points over time (velocity looks stable, but stories are smaller)
• External dependencies — Blocked work doesn't complete; velocity drops unpredictably
• Technical debt — Accumulated debt slows velocity gradually; hard to forecast

Scenario: Team has 40 velocity for 6 months. New sprint: Add 2 junior developers (team 6 → 8). Expected velocity: 40 × (8/6) = 53? Wrong. Reality: Onboarding slows seniors (mentoring time), juniors are less productive initially, communication overhead increases. Actual velocity likely drops to 35-38 for 2-3 sprints, then gradually increases. Lesson: Don't assume linear scaling. Treat team composition changes as velocity reset. Monitor and re-baseline.

Interpretation Guide

Velocity per Person (2-week sprint):

• <4 points: May indicate large stories, high overhead, or difficult domain
• 4-8 points: Typical range for most teams
• 8-12 points: High productivity or well-calibrated small stories
• >12 points: Check estimation calibration (points may be inflated)

Capacity Percentage:

• >85%: High availability; can commit to full velocity
• 70-85%: Normal; adjust velocity proportionally
• 50-70%: Significant constraints; reduce commitment substantially
• <50%: Consider canceling sprint or very limited scope

Velocity Variance (Std Dev / Mean):

• <15%: Very predictable; high confidence in forecasts
• 15-25%: Normal variance; use range for forecasting
• 25-40%: High variance; improve estimation, reduce scope changes
• >40%: Unpredictable; address root causes before forecasting

Practical Tips

• Track velocity every sprint — Even if not using for planning; builds historical baseline
• Use velocity range — Mean ± std dev for realistic forecasts; single number is false precision
• Adjust for capacity — Don't commit to 40 points when team is at 70% capacity
• Leave buffer — Commit to 85-90% of adjusted velocity; absorbs surprises
• Don't game points — If pressure to "increase velocity," points inflate, forecasting breaks
• Re-baseline after changes — New team members, new domain = reset velocity history
• Focus on predictability — Stable velocity enables planning; high variance signals problems

Common Mistakes

• Using velocity as performance metric — Leads to gaming; velocity is for forecasting, not evaluation
• Comparing across teams — Different calibration makes comparison meaningless
• Not adjusting for capacity — Full commitment on short-staffed sprint = missed goals
• Single-point estimates — "We'll finish in 5 sprints" is false precision; use range
• Extrapolating new team velocity — Need 3+ sprints before reliable baseline
• Ignoring variance — High variance team needs larger buffer, not just average

When NOT to Rely on Velocity

• New team — No history; use capacity (available hours) until 3+ sprints complete
• Exploratory work — Research, spikes, prototypes don't have predictable throughput
• External dependencies — If team is blocked 50% of time, velocity is unreliable
• One-person "team" — Individual velocity is highly variable; hours may be better
• Kanban/flow — Continuous delivery uses throughput and cycle time, not velocity

Sprint velocity and capacity planning evolved from fixed-scope project management to empirical forecasting as agile teams discovered that measuring actual throughput was more reliable than estimating individual task durations and that capacity adjustments prevented the chronic over-commitment that plagued waterfall projects.

Origins & Why It Emerged

Traditional project management (Waterfall) estimated task durations, summed them, added buffer, set deadline. Problems: (1) Duration estimates systematically wrong (optimism bias), (2) Dependencies and integration time underestimated, (3) No feedback loop—learn project was late only at the end. Agile (Scrum, XP) emerged in 1990s-2000s with different approach: short iterations, frequent delivery, empirical process control.

Velocity concept formalized in early Scrum (Schwaber, Sutherland): Measure what team actually completes, not what they estimate. Story points abstracted from hours—relative sizing (this is twice as complex as that). After 3-4 sprints, team has baseline velocity. Forecasting: Backlog size / velocity = sprints to complete. Simple, data-driven, self-correcting.

The insight: Teams are bad at estimating duration but good at comparing relative complexity. Point estimates are more stable than hour estimates. And actual throughput (velocity) is more reliable than planned throughput (estimates). The practice spread: By 2010s, velocity was standard agile metric.

How It Evolved in Practice

2000s: Velocity as planning tool. Teams tracked velocity, used for sprint commitment and release forecasting. Common mistake: Treating velocity as productivity metric (pressure to increase). Better teams understood: Velocity is for forecasting, not performance evaluation. Stable, predictable velocity is better than high, variable velocity.

2010s: Capacity planning added nuance. Raw velocity assumes full team availability. Reality: PTO, holidays, training, on-call, meetings reduce capacity. Formula: Adjusted velocity = Historical velocity × (Available capacity / Normal capacity). Teams with significant capacity variation (support rotations, holiday seasons) used capacity-based planning.

2010s-Present: Probabilistic forecasting. Instead of single-point estimates, teams use velocity range (mean ± std dev) for probabilistic forecasts: "80% confident we'll finish in 8-12 weeks." Monte Carlo simulations (1000s of random velocity samples) provide confidence intervals. Tools (Jira, Azure DevOps) automate velocity tracking and forecasting.

Modern Usage Today

Modern sprint planning: Historical velocity (6 sprints), capacity adjustment (PTO, meetings), commitment at 85-90% of adjusted velocity (buffer for unknowns). Release forecasting: Range with confidence level. Continuous improvement: If velocity drops, investigate (scope creep, tech debt, estimation drift). If variance is high, improve estimation practices.

Common Misconceptions Historically

• "Velocity should always increase" — Sustainable pace matters; stable velocity indicates healthy team
• "Compare velocities across teams" — Estimation scales differ; 40-point team isn't faster than 30-point team
• "Velocity = productivity" — Measures throughput, not value; 100 points of waste is worse than 20 points of value
• "Points = hours" — Points are relative complexity; 8-point story might take different hours for different developers
• "Velocity is fixed" — Changes with team composition, domain, tech stack; re-baseline after major changes