Sprint Velocity

Overview

Sprint Velocity measures the amount of work a team completes during a sprint, typically expressed in story points or number of tickets. Unlike DORA metrics which focus on deployment, velocity helps with capacity planning and identifying trends in team productivity.

Why It Matters

Capacity planning: Predict how much work fits in a sprint
Forecasting: Estimate project completion dates
Trend detection: Identify when team capacity changes
Resource planning: Make hiring decisions based on data
Process improvements: Measure impact of workflow changes
Realistic commitments: Avoid over or under-committing

How to Measure

Choosing Your Unit

Story Points (Recommended):

Measures relative effort, not time
Accounts for complexity and uncertainty
Less affected by estimation errors
Standard in Scrum teams

Ticket Count:

Simple to understand
Works when tickets are similar size
Can be misleading with varying complexity
Better for support/ops teams

Ideal Hours:

Time-based estimate
Can feel more precise
Often inaccurate due to interruptions
Less common in modern agile

Calculation

Sprint Velocity = Total Points/Tickets Completed in Sprint

Example (Story Points):
- Sprint 1: 34 points
- Sprint 2: 38 points
- Sprint 3: 32 points
- Average Velocity: 35 points/sprint

Example (Ticket Count):
- Sprint 1: 12 tickets
- Sprint 2: 15 tickets
- Sprint 3: 14 tickets
- Average Velocity: 14 tickets/sprint

What to Count

Include:

✅ Completed user stories (meeting Definition of Done)
✅ Completed bugs if part of sprint commitment
✅ Technical debt work if estimated
✅ Any work that delivers value

Exclude:

❌ Partially completed stories (no partial credit)
❌ Unplanned work (track separately)
❌ Spillover from previous sprints (count when completed)
❌ Blocked or postponed work

Recommended Visualizations

1. Bar Chart (Velocity Trend)

Best for: Tracking consistency over time

Y-axis: Story points completed
X-axis: Sprint number
Bars: Actual velocity
Target line: Average velocity
Annotations: Team changes, holidays, major incidents

📈 Sprint Velocity Trend

Sample data showing stable velocity around 32-38 points per sprint. The team baseline is approximately 35 points (green line). Good consistency indicates predictable delivery.

2. Team Comparison

Best for: Comparing velocity across teams

Y-axis: Story points
X-axis: Teams
Bars: This sprint vs. Last sprint
Colors: Indicate improvement or decline

👥 Team Velocity Comparison

Frontend team increased velocity by 25%. Backend and DevOps teams show slight decrease - investigate potential blockers during sprint retrospective.

3. Burndown Chart (Sprint Progress)

Best for: Tracking current sprint

Y-axis: Remaining story points
X-axis: Days in sprint
Line 1: Ideal burndown (straight line)
Line 2: Actual progress

4. Velocity Range Chart

Best for: Capacity planning

Display: Min, P25, P50 (median), P75, Max
Use for: "We typically complete 30-40 points per sprint"

Target Ranges

There is no universal target! Velocity is team-specific.

Establishing Your Baseline

Weeks 1-6: Establish baseline (don't judge)
Weeks 7-12: Refine estimation skills
Weeks 13+: Use stable velocity for planning

Healthy Velocity Characteristics

Consistency:

Good: 35, 38, 33, 36, 34 (low variance)
Concerning: 20, 45, 15, 50, 25 (high variance)

Trend:

Good: Stable or gradual increase
Concerning: Rapid increase (likely poor estimates)
Concerning: Steady decrease (burnout, attrition, technical debt)

Expected Ranges

| Condition | Expected Impact | |-----------|----------------| | New team | High variance first 3 sprints | | Team member joins | 10-20% decrease for 2 sprints | | Team member leaves | 20-30% decrease until replaced | | Major incident | 30-50% decrease for 1 sprint | | Holidays | 20-40% decrease | | Tech debt paydown | 10-20% decrease (worth it!) |

How to Use Velocity

1. Sprint Planning

Historical Velocity: 35 points/sprint
Available Capacity: 90% (one team member on vacation)
Adjusted Capacity: 35 × 0.9 = 31 points

Action: Commit to 30-32 points of work

2. Project Forecasting

Project: 200 story points
Average Velocity: 35 points/sprint
Estimated Duration: 200 ÷ 35 = 5.7 sprints ≈ 6 sprints

With uncertainty: 5-7 sprints (P25 to P75)

3. Identifying Issues

Velocity Suddenly Drops:

Team member left?
Accumulating technical debt?
Poor estimation in recent sprints?
External interruptions increased?
Morale issues?

Velocity Keeps Rising:

Team is learning (good!)
Estimation inflation (bad!)
Definition of Done loosened (very bad!)

Velocity Highly Variable:

Inconsistent story sizing
Too much unplanned work
Blocked dependencies
Team composition changing

How to Improve Velocity

⚠️ Warning: Velocity is NOT a KPI

Don't:

❌ Compare teams (different estimation scales)
❌ Push teams to increase velocity
❌ Use as performance metric
❌ Reward high velocity

Instead:

✅ Focus on consistency
✅ Improve estimation skills
✅ Remove blockers
✅ Reduce unplanned work
✅ Invest in automation

Legitimate Improvements

1. Better Estimation:

Use planning poker
Reference past stories
Break down large stories
Calibrate regularly

2. Reduce Waste:

Minimize context switching
Limit WIP (work in progress)
Clear priorities
Protect focus time

3. Remove Blockers:

Daily standups to surface issues
Clear escalation path
Reduce dependencies
Empower team decisions

4. Improve Process:

Clear Definition of Done
Faster code reviews
Better test automation
Continuous integration

5. Team Health:

Sustainable pace
Adequate capacity
Skills development
Good tooling

Common Pitfalls

❌ Velocity as Performance Metric

Problem: Teams inflate estimates to look productive Solution: Never compare team velocities or use as KPI

❌ Ignoring Context

Problem: Comparing velocity across sprints with different conditions Solution: Annotate chart with context (holidays, incidents, team changes)

❌ Partial Credit

Problem: Counting incomplete work to hit velocity targets Solution: Strict adherence to Definition of Done

❌ Pressure to Increase

Problem: Management expects velocity to always grow Solution: Educate that stable velocity is healthy

❌ Comparing Teams

Problem: Team A does 50 points, Team B does 30 points, so A is better Solution: Story points are team-specific, not comparable

❌ Focusing Only on Velocity

Problem: Ignoring quality, technical debt, team health Solution: Balance with quality metrics and team satisfaction

Implementation Guide

Week 1: Setup

1. Choose your metric (story points recommended)
2. Configure Jira/Linear/GitHub Projects
3. Define your Definition of Done
4. Document your estimation scale

Fibonacci Scale Example:
1 point: < 2 hours, trivial
2 points: Half a day, clear scope
3 points: One day, some complexity
5 points: 2-3 days, moderate complexity
8 points: Full week, high complexity
13 points: Too large, break it down

Week 2-4: Baseline

Don't judge velocity yet
Focus on consistent estimation
Complete as much as you commit to
Track completion rate

Week 5+: Use for Planning

Calculate average velocity
Identify your typical range (P25-P75)
Use for sprint planning
Forecast project timelines

Dashboard Example

Team View

┌────────────────────────────────────────────┐
│ Sprint Velocity                            │
│                                            │
│ Current Sprint: 28 / 35 points (Day 7/10) │
│ ████████████████░░░░░░░░░░░░ 80%          │
│                                            │
│ Recent Sprints:                            │
│ Sprint 47: 34 points ✓                    │
│ Sprint 46: 38 points ✓                    │
│ Sprint 45: 32 points ✓                    │
│                                            │
│ Average (12 sprints): 35 points           │
│ Typical Range: 30-40 points               │
└────────────────────────────────────────────┘

Trend Chart

Story Points
50 │                       ╭─╮
45 │                  ╭────╯ ╰─╮
40 │              ╭───╯         │
35 │ ─────────────────────────────────  Average
30 │         ╭────╯               ╰───╮
25 │    ╭────╯                        ╰─
20 │╭───╯
   └┴────┴────┴────┴────┴────┴────┴────
   S40  S42  S44  S46  S48  S50  S52

Complement Velocity with:

Cycle Time: How long does work take?
Deployment Frequency: Are we shipping value?
Code Review Time: Is review a bottleneck?
Team Retention: Is team composition stable?
Technical Debt: Are we accumulating debt?

Tools & Integrations

Native Support

Jira: Built-in velocity charts
Azure DevOps: Velocity widget
Linear: Cycle analytics
GitHub Projects: Insights (beta)
Monday.com: Sprint velocity tracking

Third-Party Tools

ActionableAgile: Advanced flow metrics
Plandek: Engineering intelligence
Pluralsight Flow: Development analytics

DIY Approach

import pandas as pd

# Load sprint data
sprints = pd.read_csv('sprints.csv')  # sprint_id, points_completed

# Calculate velocity metrics
avg_velocity = sprints['points_completed'].mean()
std_velocity = sprints['points_completed'].std()
p25 = sprints['points_completed'].quantile(0.25)
p75 = sprints['points_completed'].quantile(0.75)

print(f"Average Velocity: {avg_velocity:.1f} points")
print(f"Typical Range: {p25:.0f}-{p75:.0f} points")
print(f"Variability: {std_velocity:.1f} (lower is better)")

# Forecast project
project_points = 200
sprints_needed = project_points / avg_velocity
print(f"Project Forecast: {sprints_needed:.1f} sprints")

Questions to Ask

For Planning

What's our average velocity over the last 6 sprints?
Do we have any capacity adjustments this sprint? (PTO, holidays)
Are we consistently completing our commitments?

For Improvement

Is our velocity stable or variable?
What causes our velocity to drop?
Are we estimating consistently?
Do we have too much unplanned work?

For Leadership

Is the team's capacity stable?
Do we need to adjust project timelines?
Are we over-committing or under-committing?
Is team size appropriate for the roadmap?

Success Stories

SaaS Startup

Before: Variable velocity (15-45 points), missed commitments
After: Stable velocity (32-38 points), predictable delivery
Changes:
- Better story sizing (nothing > 8 points)
- Protected team from interruptions
- Improved Definition of Done
Impact: 90% sprint commitment rate, accurate project forecasts

Enterprise Team

Before: Declining velocity over 6 months
After: Stable, healthy velocity
Changes:
- Identified technical debt accumulation
- Allocated 20% capacity to tech debt
- Short-term velocity drop, long-term stability
Impact: Velocity stabilized, faster feature development

Advanced Topics

Capacity-Based Planning

Team: 5 engineers
Sprint: 2 weeks
Ideal Points/Person/Sprint: 8 points
Total Capacity: 5 × 8 = 40 points

Adjustments:
- Junior engineer: 0.7x = 5.6 points
- On-call rotation: -5 points
- 20% tech debt: -8 points
────────────────────────────────
Adjusted Capacity: 32 points

Velocity per Person

Total Velocity: 35 points
Team Size: 5 engineers
Per-Person Velocity: 7 points/sprint

Use for:
- Estimating impact of team size changes
- Identifying if new hires are ramping up
- NOT for individual performance reviews!

Load Factor Analysis

Committed: 40 points
Completed: 35 points
Load Factor: 35/40 = 87.5%

Healthy: 80-100%
Over-committing: < 80%
Under-committing: > 100% (shouldn't happen)

Conclusion

Sprint Velocity is a planning tool, not a performance metric. Use it to forecast timelines, plan capacity, and identify trends—but never to compare teams or pressure developers. Focus on consistency over raw numbers, and balance velocity with quality metrics and team health. A stable velocity indicates a healthy, predictable team that can reliably deliver value. Start tracking today, establish your baseline over 6-12 sprints, and use it to make better commitments and forecasts.

Remember: The goal isn't high velocity—it's predictable, sustainable, value delivery.