Team Velocity Calculator
Calculate agile team velocity as story points completed per sprint week. Use it to forecast completion of remaining backlog, plan sprint capacity, and track team productivity trends over time.
Last updated: May 2026
Compare with similar
About this calculator
Team velocity is the agile equivalent of throughput — the measurable rate at which the team converts backlog into completed work. The formula is: Velocity (points/week) = Story Points Completed / Sprint Duration (in weeks). Variables: Story Points Completed is the sum of point values of work items the team genuinely completed (met Definition of Done) during the sprint; Sprint Duration is sprint length in weeks (typically 1, 2, 3, or 4). Edge cases: partial credit for incomplete stories is debated — most agile teams use binary completion (0 points if not done, full points if done) because partial credit invites optimism and gaming; carry-over incomplete work to next sprint without points. Velocity is a TEAM-level metric, not individual — variances within the team are normal and expected. Velocity is INHERENTLY local to each team's specific story-point scale (each team estimates differently) and CANNOT be compared meaningfully across teams. Comparing velocity across teams is one of the most common antipatterns; it incentivizes inflated estimates and undermines team autonomy. Velocity should stabilize within 3–5 sprints of forming or restructuring a team; the trend is more informative than single-sprint values. Use velocity for: (1) Forecasting — remaining backlog points / velocity = estimated weeks to completion; (2) Sprint planning — pull approximately one sprint's worth of velocity into each sprint; (3) Capacity planning — adjust commitments when team size or composition changes. Don't use velocity for: performance evaluation, cross-team comparison, individual reward systems.
How to use
Example 1 — Stable scrum team. Story points completed in last sprint = 32, sprint duration = 2 weeks. Step 1: velocity = 32 / 2 = 16 points/week. Verify ✓. For sprint planning, the team should commit to approximately 32 points per 2-week sprint. For forecasting: if the remaining backlog is 200 points, estimated completion = 200 / 16 = 12.5 weeks ≈ 6-7 sprints. Add explicit buffer for unknowns: realistic forecast = 8-9 sprints. Example 2 — New team finding its rhythm. Sprint 1: 18 points completed; Sprint 2: 24 points; Sprint 3: 27 points; Sprint 4: 26 points; Sprint 5: 28 points. Sprint duration = 2 weeks. Trailing-three-sprint average velocity = (27 + 26 + 28) / 3 / 2 = 13.5 points/week. Verify ✓. The team is stabilizing around 25-28 points per sprint. Early sprints showed lower velocity as the team learned together; current stable velocity is the right number for forecasting. Cone of uncertainty: forecast range is +/- 20% (10.8 to 16.2 points/week), so 200-point backlog estimates 9-15 weeks depending on velocity variation.
Frequently asked questions
How many sprints do I need to establish reliable velocity?
Most teams need 3–5 completed sprints before velocity stabilizes. Sprint 1 velocity is almost always low because: team is learning to work together, estimation calibration is rough, infrastructure overhead dominates, Definition of Done is still being established. Sprints 2–3 typically show acceleration as the team finds rhythm. By sprints 4–5, velocity should stabilize with normal sprint-to-sprint variance of ±20%. To use velocity for forecasting: use trailing-three-sprint average rather than single-sprint values to reduce noise. Big shifts in velocity warrant investigation: dramatic drops may indicate team disruption (people leaving, sick), tooling problems, or scope changes that should be addressed; dramatic increases may indicate inflated estimates, story-point creep, or unsustainable overwork. Stable velocity is the goal — predictability matters more than maximum rate. Teams chasing 'higher velocity' often end up with point inflation that ruins forecasting accuracy without delivering more real value.
Should velocity be compared across teams?
No — this is the most common velocity antipattern. Story points are a relative-sizing tool unique to each team's specific estimation scale. One team's '5 points' might be another team's '13 points' for similar work, because each team calibrates estimates against their own historical reference stories. Comparing velocities across teams encourages: (1) Inflating estimates to appear higher-performing (point inflation); (2) Underbidding to look efficient (cherry-picking easy work); (3) Demoralizing teams scored as 'slow' when they're actually delivering excellent quality; (4) Loss of estimation accuracy as teams game the metric. Instead, compare each team against their own historical baseline — is velocity stable? Trending up or down? Are forecasts accurate? Use cross-team metrics that measure real business outcomes (customer satisfaction, defect rates, delivery predictability) rather than velocity. Managers who compare team velocities often destroy the very forecasting tool they're trying to use; experienced agile coaches strongly advise against this practice.
What are the most common mistakes with velocity?
The biggest is treating velocity as a productivity metric to maximize rather than a forecasting tool to stabilize. Maximizing velocity through point inflation or skipping refactoring eventually destroys delivery quality. The second is comparing across teams (see above). The third is using velocity for individual performance evaluation; individuals don't have velocities, teams do, and individual evaluation creates conflict and gaming. The fourth is using maximum-sprint velocity for forecasting instead of average; cherry-picking the best sprint produces optimistic forecasts that fail. The fifth is ignoring quality and only tracking velocity; teams that maintain velocity by accumulating tech debt eventually slow dramatically. The sixth is calculating velocity from stories that weren't actually done (carrying over incomplete work as 'mostly done' for full credit). The seventh is changing the story-point scale or composition of work during velocity tracking — only consistent measurement produces reliable trend data.
When should I NOT use velocity?
Skip velocity for non-agile projects with fixed scope and waterfall planning; EVM metrics (EV, SPI, CPI) are designed for those contexts. Avoid velocity for early-stage research or exploration where the unit of 'work' is unclear and story points don't apply. Do not use velocity in the first 3 sprints of a new team where the metric hasn't stabilized; use bounded delivery commitments instead. Skip velocity for teams that have dramatically changed composition (multiple new members, major reorganization) where past velocity doesn't predict future capacity. Do not use velocity as the primary metric for executive dashboards; pair with customer outcome metrics, defect rates, and time-to-value. And do not use velocity for cross-team forecasting when teams have different scales (see comparison antipattern above). Velocity is a powerful tool within a single team for forecasting and planning; outside that scope, alternatives like #stories shipped, customer outcomes, or business value delivered work better.
How do you forecast project completion using velocity?
The basic formula: Remaining Backlog (points) / Trailing-three-sprint Average Velocity = Estimated Sprints to Completion. Example: 240 remaining points with velocity 30 points/sprint = 8 sprints to complete. Convert to dates: 8 sprints × 2 weeks = 16 weeks = ~4 months. For more rigor: (1) Use confidence intervals — show forecast as range (15-21 weeks based on velocity standard deviation) not single date; (2) Update forecasts at end of each sprint based on actual velocity and remaining backlog; (3) Use throughput-based forecasting (story counts/sprint) as cross-check to velocity-based forecasting; the two should converge if estimation is consistent. Cone of uncertainty: forecast accuracy improves as project progresses, with typical ranges of ±50% in first 25% of project, ±25% at midpoint, ±10% near end. Honest forecast communication uses ranges and updates frequently; precise single-date commitments using velocity are usually wrong. The Kanban method's '85th percentile cycle time' is increasingly popular as an alternative forecast that handles variability better than velocity-based forecasting, especially for variable-sized work.