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.