Scrum Team Velocity: How to Calculate, Track, and Improve (2026)

Velocity is one of the most important metrics in Scrum. It allows you to predict how much work your team can complete and create realistic plans.

What is Velocity in Scrum?

Velocity = Sum of story points completed in a sprint

Simple, but powerful.

Basic Example

Sprint 1:
- Story A: 5 points ✅ Completed
- Story B: 8 points ✅ Completed
- Story C: 3 points ✅ Completed
- Story D: 5 points ❌ Not completed

Sprint 1 Velocity = 5 + 8 + 3 = 16 points

Critical rule: Only count 100% completed stories (according to your Definition of Done).

Why Velocity Matters

1. Realistic Planning

With historical velocity, you can predict future sprints:

Average velocity: 22 points/sprint
Backlog for release: 88 points

Prediction: 88 ÷ 22 = 4 sprints
With 2-week sprints = 8 weeks

2. Detects Problems Early

Sprint 1: 25 points
Sprint 2: 24 points
Sprint 3: 23 points
Sprint 4: 15 points ⚠️

What happened in Sprint 4?
- Team illness?
- Blocked dependencies?
- Underestimation of complexity?

3. Demonstrates Value to Business

Stakeholder: "Why only 5 features this quarter?"
You: "Our velocity is 20 points/sprint.
     Each feature is ~12 points average.
     6 sprints × 20 points = 120 points = 10 features.
     But you requested 15 features (180 points).
     Something has to give: scope, time, or quality."

Concrete data beats opinions.

How to Calculate Velocity

Step 1: Record Completed Story Points

At the end of each sprint:

Sprint Planning:
- Committed: 25 points

Sprint Review:
- Completed: 23 points (2 stories not finished)

Velocity = 23 points

Step 2: Calculate Moving Average

Use the last 3-6 sprints:

Sprint 1: 21 points
Sprint 2: 25 points
Sprint 3: 23 points
Sprint 4: 22 points
Sprint 5: 20 points
Sprint 6: 25 points

Simple average:
(21 + 25 + 23 + 22 + 20 + 25) ÷ 6 = 22.67 ≈ 23 points

Last 3 sprints average (more recent):
(22 + 20 + 25) ÷ 3 = 22.33 ≈ 22 points

Recommendation: Use last 3-4 sprints for balance between stability and relevance.

Step 3: Consider Variability

Velocity isn’t constant. Calculate standard deviation:

Sprints: 21, 25, 23, 22, 20, 25
Mean: 22.67
Standard deviation: 2.05

Interpretation:
- 68% of sprints: 20-25 points (±1 SD)
- 95% of sprints: 18-27 points (±2 SD)

For planning: Use the low range (20 points) to be conservative.

Factors Affecting Velocity

Normal Factors (Don’t Worry)

1. Vacations and Holidays

Normal sprint: 10 working days = 22 points
Sprint with holiday: 8 working days = 18 points

This is expected, not a performance problem.

2. New Team Members

Week 1-2: Low velocity (onboarding)
Week 3-8: Velocity gradually increases
Week 9+: Normalized velocity

Concerning Factors (Investigate)

1. Estimation Drift

Problem:
Sprint 1-5: "Story M" = 5 points
Sprint 6-10: "Story M" = 8 points (same type of work)

Symptom:
- Velocity increases but actual productivity doesn't
- Point inflation

Solution:
- Recalibrate estimates with reference stories
- Discuss in retrospective

2. Excessive Work In Progress

Problem:
Sprint Planning: 10 stories (25 points)
Sprint Review: 8 stories 90% complete, 2 stories 100% complete

Result: Only 2-3 points of velocity

Solution:
- Limit WIP (Work In Progress)
- "Stop starting, start finishing"
- Focus on completing few stories well

Velocity Patterns

Healthy Pattern: Stable

Sprints: 22, 23, 21, 24, 22, 23

✅ Variation < 15%
✅ Predictable
✅ Mature team

Common Pattern: Growing

Sprints: 15, 18, 20, 22, 23, 24

✅ Team learning
✅ Improving estimates
✅ Reducing waste

Caution: Ensure it's not estimation inflation.

Problematic Pattern: Erratic

Sprints: 15, 28, 12, 25, 18, 30

❌ Variation > 40%
❌ Unpredictable
❌ Underlying problems

Common causes:
- Stories too large
- External blocking dependencies
- Frequent priority changes
- Inconsistent estimates

Using Velocity for Planning

Sprint Planning

Use historical velocity to commit:

Average velocity: 22 points
Next sprint: Holiday (capacity -20%)

Safe commitment: 22 × 0.8 = 17-18 points

Select stories:
- Story A: 8 points
- Story B: 5 points
- Story C: 3 points
- Story D: 2 points
Total: 18 points ✅

Release Planning

Project dates with velocity:

Features for Q1: 120 points
Velocity: 20 points/sprint
2-week sprints

Calculation:
120 ÷ 20 = 6 sprints = 12 weeks = 3 months

But add buffer (20%):
12 weeks × 1.2 = 14.4 weeks ≈ 3.5 months

Commitment: "We'll deliver between late March and mid-April"

Improving Velocity

⚠️ Important Warning

DON’T make velocity a goal in itself.

❌ "Our goal is to increase velocity 20% this quarter"
   → Estimate inflation
   → Quality sacrifice
   → Burnout

✅ "Our goal is to deliver value consistently"
   → Stable velocity = predictability
   → Predictability = business confidence

Legitimate Improvements

1. Reduce Waste

Identify what doesn’t add value:

Time Tracking (1 week):
- Coding: 50%
- Meetings: 25%
- Waiting for reviews: 15%
- Waiting for QA: 10%

Improvement:
- Pair programming → less waiting for reviews
- Automate QA → less waiting for QA
→ More coding time without increasing work hours

2. Improve Estimates

Estimation retrospective:
- Review last 10 stories
- Which did we underestimate? Why?
- Which did we overestimate? Why?

Common:
- Underestimate testing
- Overestimate simple features with known tech

Action:
- Update reference stories
- Calibrate Definition of Done

Common Mistakes with Velocity

Mistake 1: Comparing Teams

❌ "Team A has velocity of 30, Team B only 20.
    Team B is less productive."

Why it's wrong:
- Story points are relative to each team
- Team A's "5" ≠ Team B's "5"
- Different technologies, domains, experience

✅ Compare each team to itself over time.

Mistake 2: Pressuring for Higher Velocity

❌ Manager: "I want you to increase velocity 30% next quarter"

Result:
- Team inflates estimates (5 → 8)
- Velocity goes up on paper, productivity same
- Metrics lose meaning

✅ Focus on:
   - Velocity stability (predictability)
   - Waste reduction
   - Continuous improvement

Mistake 3: Counting Partially Completed Stories

❌ 8-point story at 90%
   "Let's count 7 points of velocity"

Problem:
- It's not done per Definition of Done
- Last 10% is often 50% of work
- Incentivizes leaving stories 90% complete

✅ 0% or 100%. Nothing in between.
   If not done, it's 0 points of velocity.

Tools for Tracking Velocity

Burndown Chart

Shows remaining work vs time:

Day 1: 25 points remaining
Day 5: 15 points remaining
Day 10: 0 points remaining ✅

If current line is above ideal line:
→ Risk of not completing sprint

Velocity Chart

Compares velocity across sprints:

Sprint 1: ████████████████████░░ 22 points
Sprint 2: ██████████████████████ 25 points
Sprint 3: ████████████████████░░ 21 points
Sprint 4: ████████████████████░░ 23 points

Average: 22.75 points
Trend: Stable ✅

Conclusion

Velocity is a planning tool, not a performance goal.

Use it for:

• ✅ Predicting realistic dates
• ✅ Detecting problems early
• ✅ Improving estimates
• ✅ Demonstrating capacity to stakeholders

DON’T use it for:

• ❌ Comparing teams
• ❌ Evaluating individual performance
• ❌ Pressuring for “more productivity”
• ❌ Bonuses or punishments

The best velocity is stable and predictable, not necessarily the highest.

Start Measuring Your Velocity

Ready to start? Create your first Planning Poker session and start tracking completed story points.

Related Resources

• Planning Poker: Complete Guide
• Fibonacci in Agile Estimation
• Remote Planning Poker Guide