Understanding Sprint Velocity
| Team Size |
Expected Velocity Range |
Notes |
| 3–4 members | 15–35 points/sprint | Small, focused team |
| 5–7 members | 30–60 points/sprint | Typical Scrum team |
| 8–10 members | 50–90 points/sprint | Larger team |
| Cross-functional | Varies widely | Depends on experience |
| New team | Lower first 3–5 sprints | Ramp-up period |
| Stable team | Consistent ±10% | Predictable after ~6 sprints |
| Scale |
Point Values |
When to Use |
| Fibonacci | 1, 2, 3, 5, 8, 13, 21 | Most common; built-in uncertainty |
| Modified Fibonacci | 1, 2, 3, 5, 8, 13, 20, 40, 100 | Adds milestone markers |
| T-shirt sizes | XS, S, M, L, XL, XXL | Non-technical stakeholders |
| Powers of 2 | 1, 2, 4, 8, 16, 32 | Simpler scale |
| Linear | 1, 2, 3, 4, 5, 6, 7, 8 | Least recommended |
| Key rule | Anything >13 should be split | Reduces estimation error |
| Sprint Length |
Pros |
Cons |
Best For |
| 1 week | Fast feedback, high adaptability | Planning overhead high | R&D, fast-changing requirements |
| 2 weeks | Standard; balance of stability/flexibility | Most common | Most teams |
| 3 weeks | Larger features possible | Less frequent retrospection | Hardware-integrated work |
| 4 weeks | Minimal ceremony overhead | Low adaptability, late feedback | Legacy/waterfall transition |
Sprint velocity is a key metric in agile development that measures the amount of work a team can complete during a sprint. By understanding and tracking velocity, teams can better plan sprints, forecast project completion, and identify areas for improvement. This guide covers how to calculate, use, and improve sprint velocity.
What is Sprint Velocity?
Definition
Sprint velocity is the sum of story points completed by a team during a sprint. It represents the team's historical capacity and is used for:
- Sprint planning and commitment
- Release planning and forecasting
- Identifying capacity trends
- Comparing team performance over time
Why Story Points?
Story points measure relative effort and complexity rather than time:
- Account for complexity, uncertainty, and effort
- More stable than hour estimates
- Team-specific and not comparable across teams
- Encourage collaboration in estimation
Calculating Velocity
Basic Velocity Formula
Velocity = Sum of story points from completed user stories
- Only count fully completed stories
- Partially completed stories don't count
- Calculate at the end of each sprint
- Use rolling average of last 3-5 sprints
Capacity Calculation
Capacity = Team Size x Sprint Days x Availability x Focus Factor
| Factor |
Typical Range |
Description |
| Team Size |
3-9 members |
Active developers |
| Sprint Days |
5-20 days |
Working days in sprint |
| Availability |
70-90% |
PTO, meetings, support |
| Focus Factor |
60-80% |
Time on sprint work |
Velocity Trends
Interpreting Velocity Changes
| Trend |
Possible Causes |
Actions |
| Increasing |
Team maturing, better processes, reduced debt |
Document what's working |
| Stable |
Mature team, consistent practices |
Ideal state for forecasting |
| Decreasing |
Technical debt, team changes, external factors |
Retrospective investigation |
| Highly Variable |
Inconsistent estimation, scope changes |
Focus on estimation practices |
Velocity Variance
Track velocity variance to understand predictability:
- Low variance (less than 15%): Highly predictable team
- Medium variance (15-25%): Typical agile team
- High variance (more than 25%): Forecasting challenges
Sprint Planning Best Practices
Using Velocity for Planning
- Calculate average velocity from last 3-5 sprints
- Account for known absences and holidays
- Consider any special circumstances
- Commit to 80-90% of calculated capacity
- Keep buffer for unexpected work
Commitment Guidelines
| Confidence Level |
Points to Commit |
Use Case |
| Conservative |
Avg - Variance |
External deadlines |
| Normal |
Average |
Regular sprints |
| Aggressive |
Avg + (Variance/2) |
Stretch goals |
Release Forecasting
Calculating Sprints to Completion
Sprints Needed = Remaining Story Points / Average Velocity
Forecasting with Confidence Ranges
- Optimistic: Points / (Velocity + Variance)
- Likely: Points / Velocity
- Pessimistic: Points / (Velocity - Variance)
Improving Velocity
Legitimate Ways to Improve
- Reduce technical debt
- Improve development practices (CI/CD, testing)
- Remove impediments
- Better backlog refinement
- Reduce context switching
- Improve team collaboration
Focus Factor Improvements
| Issue |
Impact on Focus |
Solution |
| Too many meetings |
-10-20% |
Consolidate, make optional |
| Support interruptions |
-5-15% |
Rotate support duty |
| Unclear requirements |
-10-20% |
Better refinement |
| Technical debt |
-10-30% |
Allocate cleanup time |
Conclusion
Sprint velocity is a valuable tool for planning and forecasting when used correctly. Focus on trends rather than absolute numbers, use historical data for predictions, and resist the temptation to optimize velocity at the expense of quality. Remember that velocity is a planning tool, not a performance metric - the goal is predictable delivery of value, not maximizing story points.
Frequently Asked Questions
How accurate are the results?
The Sprint Velocity applies a standard formula to your inputs — accuracy depends on how precisely you measure those inputs. For planning and estimation, results are reliable. For high-stakes or professional decisions, cross-check the output with a domain expert or primary source.
Can I use this on mobile?
Yes — the calculator is designed to work on any device. For complex multi-input calculations on small screens, landscape orientation gives more room to see all fields and results simultaneously.
What is sprint velocity in Agile/Scrum?
Sprint velocity is the amount of work a Scrum team completes in a single sprint, measured in story points (or sometimes hours or story count). It is one of the most important metrics for Agile planning. How velocity is measured: At the end of each sprint, the team counts the story points from completed (fully done, meeting Definition of Done) user stories. Partially completed stories count as zero. This total is the sprint velocity. Example: Sprint 1: completed stories with points 3, 5, 8, 5, 3 → velocity = 24. Sprint 2: completed stories 5, 8, 13, 5 → velocity = 31. Sprint 3: 8, 8, 5, 3, 5 → velocity = 29. Rolling average: average velocity = (24 + 31 + 29) / 3 = 28 points/sprint. What velocity measures: Velocity reflects a specific team's throughput given its current composition, working conditions, definition of done, and estimation practices. It is not comparable between teams — a team with 40 points/sprint is not necessarily faster than one with 20 points/sprint (they may estimate differently). Using velocity for planning: With a stable velocity, you can forecast: Sprints remaining = remaining backlog points / average velocity. Release date = today + (sprints remaining × sprint length). Velocity is most predictable after 3–5 sprints and stabilizes after ~6 sprints with the same team. Important caveats: Velocity should never be used to compare teams. Never increase velocity artificially by inflating story points. It's a planning tool, not a performance metric. "Commitment" to hit a specific velocity creates counterproductive pressure.
How do you calculate average sprint velocity?
Average sprint velocity is typically calculated using the last 3–5 completed sprints. Why 3–5 sprints: Too few (1–2): one outlier skews the estimate. Too many (10+): older data includes past team compositions, processes, and conditions that no longer apply. 3–5 is the sweet spot for recency and statistical stability. Calculation: Simple average: Sum the last 3–5 sprint velocities and divide by the number of sprints. Example: Sprints: 28, 31, 24, 29, 33. Average velocity = (28 + 31 + 24 + 29 + 33) / 5 = 29 points/sprint. Weighted average (optional): Some teams give more weight to recent sprints. Example: give last sprint 40% weight, second-to-last 30%, third 20%, fourth 10%. Helps if the team recently changed size or process. Velocity range (more honest): Rather than a single number, report velocity as a range: Low estimate: use minimum velocity from recent sprints. High estimate: use maximum velocity. This captures natural variability and gives more realistic forecasts. Example: min = 24, max = 33 → forecast: "Between 24 and 33 points per sprint." Adjusting for planned interruptions: Reduce velocity proportionally for known absences: a 5-person team with 1 member on vacation for a whole sprint loses 20% capacity. Planned holiday sprints typically run at 50–70% velocity. New team members: initially reduce velocity. A new member often reduces team velocity short-term (ramp-up, pairing, code review). After 1–2 sprints, velocity usually increases. Adding 1 member to a 5-person team may decrease velocity by 10–20% for 2–3 sprints before net improvement.
What is a good sprint velocity?
"Good" velocity is highly relative and team-specific — there is no universal benchmark. What matters is not the number itself, but whether velocity is consistent and whether the team can plan accurately from it. Why comparison is meaningless: Two teams with identical skills and output could have velocities of 30 and 90 points/sprint — simply because one team uses smaller point values on average. Story point calibration varies by team. Point inflation is common when teams are measured on velocity. Signs of a healthy velocity: Stability: velocity varies by less than ±20% sprint-to-sprint (excluding planned capacity changes). Accuracy: the team consistently completes what it forecasts. No artificial inflation: the team isn't gaming story point estimates. Trend: velocity grows over time as the team matures. Typical ranges (rough, team-specific): New team (3–6 months): 20–40 points/sprint (2-week sprint, 5–7 members). Mature team: 30–70 points/sprint. Common warning signs: Velocity spikes: caused by point inflation, not real improvement. "Everything is 8 points" anti-pattern. Constantly missing commitments: teams under pressure to hit velocity targets overcommit and cut quality. Using velocity for performance reviews: creates perverse incentives to inflate estimates. Velocity declining: can indicate technical debt accumulation, key person loss, or process problems — worth investigating. The right question: "Is our velocity stable enough to plan 2–3 sprints ahead?" is more useful than "Is our velocity high enough?"
What is the difference between velocity and capacity in Scrum?
Velocity and capacity are related but distinct Scrum concepts, and confusing them leads to poor planning. Velocity: A historical measure of actual completed work (story points/sprint). Based on what the team actually finished, measured over past sprints. Used for forecasting future throughput. Example: "Our average velocity is 32 points." Capacity: A forward-looking estimate of team availability for the next sprint. Based on who is available and for how many hours. Expressed in person-hours or person-days. Example: "We have 4 developers at 40 hours each = 160 hours of capacity this sprint." How they interact during sprint planning: 1. Determine capacity: count available team members and hours, subtract meetings, PTO, and other non-sprint-work time. 2. Adjust velocity for capacity changes: if this sprint's capacity is 80% of typical, expect 80% of average velocity. 3. Pull work from backlog to match the adjusted velocity estimate. The formula for capacity-adjusted velocity: Expected velocity = Average velocity × (Available hours / Typical sprint hours). Example: typical velocity = 32 points, typical capacity = 160 hours. This sprint: 2 members out for 2 days each = 144 hours. Adjusted expected velocity = 32 × (144/160) = 28.8 → plan for ~28–29 points. When to use each: Velocity: for long-range forecasting (release dates, roadmap planning). Capacity: for sprint-level planning (which stories to pull, sprint commitment). Best practice: always calculate capacity before committing to a sprint. Never use last sprint's velocity as a commitment if capacity has changed.