📈

What Is Sprint Velocity?

Velocity is the amount of work a team completes in a single sprint, measured in story points. It's not a performance metric—it's a planning tool that helps teams predict how much work they can reliably commit to in future sprints.

Think of velocity as your team's "capacity fingerprint." After 3-4 sprints, patterns emerge. Some teams average 25 points per sprint. Others average 50. Neither is better—they're just using different scales.

3-4
Sprints to Stabilize
±15%
Healthy Variance
10-20%
Tech Debt Budget
70%
Min Completion Rate
🧮

How to Calculate Velocity

Basic Formula
Velocity = Σ Points (Done Stories Only)
Sum of story points for all stories marked "Done" at sprint end

✓ Count These

  • Fully completed stories
  • Stories meeting DoD
  • Deployed to production (or staging if that's your DoD)

✗ Don't Count These

  • Partially done work
  • Stories "90% complete"
  • Code in review but not merged

⚡ Advanced Formula

avg_velocity = total_points / sprint_count

Average over 3-6 sprints for better predictions. Exclude sprints with major disruptions (holidays, team changes).

📊

Velocity Trend Example

1

Sprint 1

23 of 28 points completed

23
82%
→ Stable
2

Sprint 2

21 of 25 points completed

21
84%
→ Stable
3

Sprint 3

27 of 30 points completed

27
90%
↗ Improving
4

Sprint 4

29 of 29 points completed

29
100%
↗ Improving
5

Sprint 5

31 of 30 points completed

31
103%
↗ Improving
6

Sprint 6

18 of 30 points completed

18
60%
↘ DecliningInvestigate: team vacation or unexpected blockers?

Average Velocity: 25 points per sprint(Use this for future sprint planning)

🚨

Velocity Anti-Patterns: What NOT to Do

Velocity as Performance Metric

high Risk

Problem: Using velocity to compare teams or evaluate individual performance destroys trust and encourages gaming the system.

Consequence: Teams inflate estimates to look more productive. Numbers become meaningless.

Solution: Velocity is for planning capacity, not measuring productivity. Each team's velocity is unique.

Pressuring Teams to Increase Velocity

high Risk

Problem: Management sets velocity targets or demands continuous increases sprint after sprint.

Consequence: Story point inflation. A "5" becomes an "8" for the same work. Velocity rises, but throughput doesn't.

Solution: Accept that healthy teams plateau. Focus on delivering value, not hitting arbitrary numbers.

Counting Incomplete Stories

medium Risk

Problem: Giving partial credit for stories that aren't "done" by sprint end.

Consequence: Velocity becomes a vanity metric. Sprint goal accountability disappears.

Solution: Only count fully completed stories. Move incomplete work to the next sprint at full points.

Changing Points After Completion

medium Risk

Problem: Re-estimating stories after they're done because they took longer or shorter than expected.

Consequence: Historical velocity data becomes corrupted and useless for future planning.

Solution: Keep original estimates. Use variance as a learning opportunity, not a correction mechanism.

Ignoring Velocity Drops

medium Risk

Problem: Dismissing sudden velocity decreases as anomalies instead of investigating root causes.

Consequence: Underlying problems (technical debt, process issues, team morale) go unaddressed.

Solution: Treat velocity drops as signals. Hold a retrospective to understand what changed.

🎯

How to Improve Velocity (Without Gaming It)

Reduce Work in Progress

High

Limit concurrent stories. Finish what you start before starting new work.

Action Steps

Set WIP limits per person (1-2 stories max). Mob on blockers instead of starting new work.

Improve Story Breakdown

High

Smaller stories flow faster and reduce estimation error. Aim for 3-5 points per story.

Action Steps

If a story is over 8 points, break it down. Use INVEST criteria for good stories.

Address Technical Debt

Medium

Allocate 10-20% of sprint capacity to paying down tech debt and refactoring.

Action Steps

Create explicit tech debt stories. Track them alongside features. Make the cost visible.

Eliminate Context Switching

Medium

Protect the team from interruptions, unplanned work, and meeting overload.

Action Steps

Block focus time. Create an interrupt buffer. Track unplanned work separately.

Improve Definition of Done

Medium

Clear DoD prevents rework and reduces stories bouncing back from QA.

Action Steps

Document DoD. Include testing, documentation, and deployment criteria. Review in refinement.

Automate Repetitive Work

Low

Testing, deployments, and code reviews can be partially automated.

Action Steps

Invest in CI/CD pipeline. Add linters and formatters. Reduce manual QA overhead.

⚠️

When to Worry About Velocity Changes

🔴Red Flags (Investigate Immediately)

  • Velocity drops by 30%+ for 2+ consecutive sprints
  • Teams consistently complete less than 60% of planned work
  • Velocity wildly fluctuates (15 → 45 → 20) after initial stabilization
  • Story points steadily increase but work output stays the same

🟢Normal Variations (Don't Panic)

  • ±15% fluctuation sprint-to-sprint is healthy and expected
  • Lower velocity during holiday sprints or team training
  • Temporary dip when onboarding new team members
  • Gradual plateau after initial growth period (this is maturity!)

✓ Key Takeaways

  • 1Velocity is for planning capacity, not measuring performance. Never compare teams.
  • 2Only count fully completed stories. No partial credit. No credit for "almost done."
  • 3Average velocity over 3-6 sprints. Single sprint numbers are too volatile.
  • 4Healthy teams plateau. Continuous velocity increases usually mean estimate inflation.
  • 5Improve velocity by improving process, not by manipulating estimates.

Start Planning with Velocity

Use our free planning poker tool to estimate story points and build a reliable velocity baseline for your team.

Create Free Planning Poker Room