Velocity

Velocity measures how much work a team completes in a sprint, typically expressed in story points. It's a planning tool that helps teams predict how much they can commit to in future sprints based on historical performance. A team that consistently completes 40 story points per sprint can reasonably plan around that capacity going forward.

Why it matters

Without some measure of capacity, sprint planning becomes guesswork. Teams either overcommit and fail to deliver, or undercommit and waste capacity. Velocity provides an empirical basis for commitment - not a perfect prediction, but a reasonable starting point grounded in actual performance rather than optimism.

Velocity also enables longer-range forecasting. If your roadmap contains 200 story points of work and your team's velocity is 40 points per sprint, you can estimate roughly five sprints of effort. This helps set expectations with stakeholders and identify when scope or timeline adjustments are needed.

Calculating velocity

Velocity calculation is straightforward: sum the story points of all items completed during the sprint. "Completed" means meeting the Definition of Done - not started, not almost done, but actually done.

Most teams average velocity over several sprints (typically three to five) to smooth out variation. A single sprint might be unusually productive or disrupted by illness or holidays; averaging provides a more reliable baseline.

Example calculation:

This team can reasonably commit to around 40 points in sprint planning, though they might flex slightly based on circumstances.

Using velocity effectively

Velocity serves specific purposes and fails when misused.

Do use velocity for:

Don't use velocity for:

The distinction is important. Velocity is a team-internal planning tool, not a productivity metric for management.

Velocity anti-patterns

Several common patterns destroy velocity's usefulness:

Velocity as a target. When teams are pressured to increase velocity, they inflate point estimates. Suddenly everything takes more points, velocity "improves," but actual output doesn't change. The metric becomes meaningless.

Comparing across teams. Team A completes 60 points per sprint; Team B completes 30. Is Team A twice as productive? Impossible to know. Story point scales aren't calibrated across teams. Team B might estimate more conservatively or work on harder problems.

Ignoring variation. Velocity fluctuates. Treating it as a fixed commitment rather than a range creates problems. A team that averages 40 points might complete anywhere from 30 to 50 in a given sprint.

Counting incomplete work. If a team includes partially-done items in velocity, the measure loses predictive power. Only count what's truly complete.

Changing estimation practices. If story point definitions shift mid-stream, historical velocity becomes unreliable. Consistency matters more than precision.

Velocity and team changes

Velocity is team-specific and changes when the team changes. Adding a person doesn't immediately increase velocity - there's onboarding time, and team dynamics shift. Losing a person has the same effect. After team changes, treat velocity as unstable until a new pattern emerges.

This is another reason velocity can't be used for cross-team comparison. It's a property of a specific team in a specific context, not a universal measure of productivity.

Velocity vs. throughput

Velocity measures story points; throughput measures items completed regardless of size. Both have value.

Velocity accounts for item size, which helps with planning when work items vary significantly. But it requires the overhead of estimation and is subject to estimation inconsistency.

Throughput avoids estimation overhead and provides a more objective count. It works well when items are roughly similar in size or when you've deliberately limited work-in-progress to comparable chunks.

Some teams track both: velocity for capacity planning, throughput for flow analysis.

The estimation debate

Velocity depends on story point estimation, and story points are controversial. Critics argue that estimation time would be better spent building, and that estimates are often inaccurate anyway.

Defenders argue that estimation forces useful discussion about scope and complexity, and that velocity planning - while imperfect - beats having no capacity model at all.

Pragmatically, velocity works well for teams that estimate quickly and consistently, and poorly for teams that agonize over exact point values. The planning value shouldn't require extensive estimation overhead.

Improving velocity

Sustainable velocity improvement comes from removing obstacles and improving practices, not from working harder or inflating estimates.

Legitimate approaches include:

The goal is completing more actual work, not manufacturing better-looking numbers.

Velocity in organizational context

When stakeholders ask about velocity, it's usually because they want to understand capacity and predictability. Translate velocity into terms they care about: "We can deliver roughly X features per quarter" or "At current pace, we'll complete the roadmap by Q3."

Tools like Klero help connect velocity to customer impact by linking completed work to customer requests and feedback. This makes velocity discussions more meaningful - it's not just about points shipped but about customer needs addressed.