Sprint Velocity & Capacity Forecast
Forecast sprint capacity and release timelines with velocity variance. Enter values for instant results with step-by-step formulas.
Frequently Asked Questions
What is sprint velocity?
Velocity is the amount of work (story points) a team completes per sprint on average. Measured empirically: Sum completed points over last 3-6 sprints, divide by sprint count. Example: Team completed 35, 42, 38, 45 points over 4 sprints. Velocity = (35+42+38+45)/4 = 40 points/sprint. Use for forecasting: 200-point backlog at 40 velocity = 5 sprints. Important: Velocity is team-specific—don't compare across teams. A '40-velocity' team isn't faster than '30-velocity' team; they estimate differently. Track trend, not absolute number.
How do I calculate sprint capacity?
Capacity = Available work hours for the sprint. Formula: (Team members × Work days × Hours/day) - PTO - Meetings - Other commitments. Example: 6-person team, 10 work days, 8 hrs/day = 480 hrs total. Minus: 2 days PTO (16 hrs), 10 hrs meetings/person (60 hrs), 20% buffer (80 hrs). Available: 480 - 16 - 60 - 80 = 324 hrs. If velocity is 40 points at full capacity, adjusted = 40 × (324/480) = 27 points. Use capacity to adjust velocity when team has unusual sprint (holidays, on-call, training).
How many sprints of data do I need for reliable velocity?
Minimum 3 sprints, ideally 6-8 for reliable average. Early sprints (1-2): Velocity unstable—team forming, learning, calibrating estimates. Mid-term (3-5): Pattern emerges, use average with caution. Mature (6+): Reliable baseline; use standard deviation for confidence range. New teams: Start with capacity-based planning (hours available), transition to velocity after 3 sprints. Warning: Major changes (team composition, tech stack, product area) reset velocity—treat as new team.
What is a good velocity for a team?
No universal 'good' velocity—it's team-specific. Factors: (1) Estimation calibration (some teams use 1-5 scale, others 1-100), (2) Story granularity (big stories = fewer points completed), (3) Team skill and domain experience, (4) Technical debt and code quality. Benchmarks (rough): 5-10 points per person per 2-week sprint is common. So 6-person team: 30-60 points. But a team doing 25 points of well-estimated, high-quality work is better than 80 points of poorly-scoped, buggy work. Focus on trend (improving?) and predictability (consistent?), not absolute number.
How do I handle velocity variance in forecasting?
Use range, not single number. Calculate standard deviation of last 6 sprints. Example: Velocities 35, 42, 38, 45, 40, 36. Mean: 39.3. Std dev: 3.6. Forecast: 39 ± 4 (pessimistic 35, optimistic 43). For 200-point backlog: Pessimistic: 200/35 = 6 sprints. Expected: 200/39 = 5 sprints. Optimistic: 200/43 = 5 sprints. Communicate range to stakeholders: 'We'll complete in 5-6 sprints, most likely 5.' High variance (>25% of mean) signals estimation problems or scope instability—address root cause.
Should velocity increase over time?
Not necessarily—stable is often better than increasing. Velocity growth reasons: Team gelling, better tools, reduced tech debt, clearer requirements. Velocity plateau: Team at sustainable pace, complexity matches estimates—this is healthy. Velocity decline: Burnout, increased complexity, technical debt accumulation, team changes. Warning signs: Pressure to 'increase velocity' leads to gaming (inflating points) or cutting quality. Better metric: Value delivered (features shipped, customer impact) not points completed. Sustainable, predictable velocity > artificially high velocity.