Velocity is the total story points completed by the team in a sprint. Tracked over time, velocity becomes a planning tool — it tells you how much work the team can realistically commit to, enables forecasting for release dates, and reveals trends in team productivity.

Velocity Tracking Guide: Measure and Improve Sprint Delivery

Velocity is the most commonly tracked Agile metric, and also the most commonly misused. Used correctly, it helps teams plan accurately. Used incorrectly — as a performance metric, a comparison between teams, or a target to be maximized — it creates perverse incentives that damage both planning accuracy and team morale.

How Velocity Works

At the end of each sprint, sum the story points of all items that meet the definition of done. Partially complete items count as zero — a story at 90% is not done, so its points are not counted.

Sprint 1: Completed 28 points Sprint 2: Completed 32 points Sprint 3: Completed 25 points Sprint 4: Completed 30 points

Average velocity over 4 sprints: 28.75 points. For the next sprint, the team should plan for approximately 29 points.

Using Velocity for Planning

Sprint Planning

The team’s average velocity over the last 3-5 sprints is the primary input for sprint planning capacity. If average velocity is 29, commit to approximately 29 points of work. Adjust for known capacity changes:

Team member on PTO: reduce proportionally (if 1 of 5 members is absent, reduce by 20%)
Holiday in the sprint period: reduce proportionally
New team member: expect velocity to dip for 2-3 sprints as the team integrates

Release Forecasting

If the release backlog contains 120 points of committed scope and the team’s velocity is 30 points per sprint, expect approximately 4 sprints (8 weeks for 2-week sprints) to complete. Add contingency for scope changes and estimation errors — a realistic forecast is 5-6 sprints.

Provide a range rather than a point estimate: “Based on current velocity, we’ll be done in 4-6 sprints, most likely 5.” The range communicates confidence level and avoids false precision.

Roadmap Planning

For longer-term roadmap discussions, use velocity to sanity-check the plan. If the annual roadmap contains 600 points of work and the team delivers 30 points per sprint across 26 sprints per year (780 points capacity), the plan is feasible with buffer. If the roadmap contains 1,000 points, the team needs to cut scope or add capacity.

Velocity Chart

Plot velocity per sprint on a bar chart over time. Most PM tools (Jira, ClickUp, Linear) generate this automatically.

What to look for:

Stable velocity (within 15-20% variation). This is healthy. Normal sprint-to-sprint variation comes from story complexity, PTO, and unplanned work.

Steadily increasing velocity. Could indicate the team is genuinely improving (process improvements, better grooming, less unplanned work). Could also indicate point inflation — calling 3-point stories 5-pointers to show higher numbers.

Steadily decreasing velocity. Investigate: Is the team losing members? Is unplanned work increasing? Are stories becoming more complex? Is the team burning out? A velocity decline over 3+ sprints warrants a dedicated retrospective discussion.

Erratic velocity (swinging from 15 to 45). Indicates inconsistent estimation, inconsistent sprint scope, or a volatile work environment. Focus on stabilizing estimation practices and protecting the team from mid-sprint disruptions.

Improving Velocity (The Right Way)

Velocity is a measurement, not a target. Trying to “increase velocity” directly leads to gaming the metric. Instead, focus on the factors that naturally cause velocity to improve:

Reduce Unplanned Work

Track the percentage of sprint capacity consumed by unplanned items (bugs, production incidents, ad-hoc requests). If 30% of capacity goes to unplanned work, addressing the sources of that work directly increases available capacity for planned items.

Improve Backlog Quality

Stories that enter sprint planning with vague acceptance criteria, missing designs, or unresolved dependencies waste time during the sprint. Better backlog grooming means less re-clarification during execution.

Reduce Blockers

Track blocker duration (time from blocker raised to resolved). Shortening blocker resolution time reduces idle time and keeps work flowing. The Scrum Master’s impediment removal work directly affects this.

Limit Work in Progress

Teams that work on too many items simultaneously finish fewer items per sprint. WIP limits force focus on completion over starting, which increases throughput.

Invest in Technical Practices

Automated testing reduces manual QA time per story. CI/CD reduces deployment friction. Code review practices reduce defects. Technical practices compound — investing one sprint in test automation may save fractional effort on every subsequent sprint.

What Not to Do with Velocity

Do not compare teams. Team A’s 40 and Team B’s 25 do not mean Team A is better. They estimate differently, work on different types of problems, and have different team sizes. Comparing velocity across teams is meaningless and destructive.

Do not set velocity targets. “Increase velocity by 20% this quarter” incentivizes inflating estimates. If a 3-point story becomes a 5-point story, velocity “increases” without any actual productivity change.

Do not use velocity in performance reviews. The moment velocity is linked to compensation or evaluation, teams game the number. Velocity serves planning. Other metrics serve performance: customer impact, code quality, stakeholder feedback.

Do not count incomplete items. A story that is 90% complete but not done is zero points for velocity. This prevents the “we did a lot of work but didn’t finish anything” sprint from looking successful in the data. It also motivates teams to focus on finishing items rather than starting them.

Beyond Velocity: Complementary Metrics

Velocity alone does not tell the full story. Combine it with:

Sprint goal achievement rate. Did the team achieve the sprint goal? You can have high velocity but miss the goal if the wrong items were completed.
Cycle time. How long does a typical item take from start to done? Shorter cycle time indicates better flow.
Defect rate. How many bugs are created per sprint? High velocity with a high defect rate means the team is shipping fast but low quality.
Sprint completion rate. What percentage of committed items were completed? Consistently below 80% indicates over-commitment.

See agile metrics that matter for the full picture of team health measurement.

Velocity is a compass, not a speedometer. It helps you navigate — plan sprints, forecast releases, and detect trends — but it does not measure how hard the team is working or how much value they are creating. Treat it as a planning input, protect its integrity, and pair it with metrics that capture what velocity cannot.