Understanding Team Velocity in Agile: How to Measure and Improve

Team velocity is one of the most misunderstood Agile metrics. Used correctly, it improves planning and delivery predictability. Used incorrectly, it creates pressure, gaming, and toxic culture. Here’s how to use velocity correctly to improve your team’s planning and delivery.

What Is Velocity?

Definition

Velocity: The amount of work a team completes per sprint, measured in story points (or hours/features).

Key Characteristics:

• Team-specific (not comparable across teams)
• Relative measure (not absolute)
• Used for planning (not performance evaluation)
• Tracks trends (not absolute numbers)

Purpose:

• Predict future capacity
• Improve sprint planning
• Track trends over time
• Identify issues early

How to Measure Velocity

Story Points

What Are Story Points?

Story points measure relative complexity, not time. They’re team-specific and relative.

Common Scales:

Fibonacci Scale:

• 1, 2, 3, 5, 8, 13, 21
• Most common
• Reflects uncertainty in larger items
• Prevents false precision

Power of 2 Scale:

• 1, 2, 4, 8
• Simpler
• Less granular
• Good for smaller teams

T-Shirt Sizes:

• XS, S, M, L, XL
• Convert to numbers
• Intuitive
• Less precise

Estimation Methods:

1. Planning Poker

• Team estimates together
• Discuss differences
• Reach consensus
• Knowledge sharing

2. Relative Sizing

• Compare to reference story
• “This is like that story”
• Relative, not absolute
• Team agreement

3. Team Consensus

• Team discusses
• Agrees on size
• Shared understanding
• Collaborative

Benefits of Story Points:

• Relative, not absolute (avoids time pressure)
• Team-specific (each team has own scale)
• Focuses on complexity (not just time)
• Not time-based (avoids hour tracking)

Calculating Velocity

Basic Formula:

Velocity = Sum of story points completed in sprint

Example:

Sprint 1:
- Story A: 5 points ✓
- Story B: 3 points ✓
- Story C: 8 points ✓
- Story D: 5 points ✓
Total: 21 points

Sprint 2:
- Story E: 5 points ✓
- Story F: 8 points ✓
- Story G: 5 points ✓
- Story H: 3 points ✓
- Story I: 2 points ✓
Total: 23 points

Sprint 3:
- Story J: 5 points ✓
- Story K: 8 points ✓
- Story L: 5 points ✓
- Story M: 2 points ✓
Total: 20 points

Average Velocity: (21 + 23 + 20) / 3 = 21.3 points

Best Practice: Use 3-5 sprint average for planning

Why Average?

• Smooths out variations
• Accounts for different story types
• More reliable than single sprint
• Better for planning

Velocity Tracking:

Sprint | Points Completed | Running Average
-------|------------------|----------------
1      | 21               | 21.0
2      | 23               | 22.0
3      | 20               | 21.3
4      | 22               | 21.5
5      | 24               | 22.0

Using Velocity

1. Sprint Planning

How to Use:

Step 1: Calculate Average Velocity

Average Velocity = Sum of last 3-5 sprints / Number of sprints

Example:
Last 5 sprints: 21, 23, 20, 22, 24
Average: 22 points

Step 2: Plan 70-80% of Average

Plan = Average Velocity × 0.75

Example:
Average velocity: 22 points
Plan: 22 × 0.75 = 16.5 points
Round to: 16-17 points

Step 3: Select Stories

• Select stories totaling planned points
• Align with sprint goal
• Ensure stories are ready
• Team commits

Why 70-80%?

• Leaves buffer for unknowns
• Accounts for support work
• Reduces pressure
• Improves quality

Example:

Average Velocity: 20 points
Plan: 14-16 points (70-80%)
Buffer: 4-6 points for:
- Unknown work
- Bug fixes
- Support requests
- Learning time

Stories Selected:
- Story 1: 5 points
- Story 2: 5 points
- Story 3: 3 points
- Story 4: 3 points
Total: 16 points ✓

2. Release Planning

How to Use:

Step 1: Estimate Backlog

• Estimate all stories in backlog
• Use story points
• Total the points

Step 2: Divide by Velocity

Sprints Needed = Total Backlog Points / Average Velocity

Example:
Backlog: 100 points
Average velocity: 20 points/sprint
Sprints needed: 100 / 20 = 5 sprints

Step 3: Estimate Timeline

Timeline = Sprints Needed × Sprint Length

Example:
Sprints needed: 5
Sprint length: 2 weeks
Timeline: 5 × 2 = 10 weeks

Step 4: Plan Releases

• Group stories into releases
• Set release dates
• Communicate timeline
• Manage expectations

Example:

Release 1.0 (Target: 8 weeks)
- Backlog: 80 points
- Velocity: 20 points/sprint
- Sprints needed: 4 sprints
- Timeline: 8 weeks

Release 1.1 (Target: 12 weeks)
- Backlog: 40 points
- Velocity: 20 points/sprint
- Sprints needed: 2 sprints
- Timeline: 4 weeks (after 1.0)

3. Capacity Planning

How to Use:

Track Velocity Trends:

• Is velocity increasing?
• Is velocity stable?
• Is velocity decreasing?
• What’s the trend?

Adjust for Changes:

• Team size changes
• Team member changes
• Process changes
• Context changes

Plan Resources:

• How many teams needed?
• What capacity required?
• When can we deliver?
• Resource allocation

Set Expectations:

• Realistic timelines
• Manage stakeholder expectations
• Communicate capacity
• Plan accordingly

Example:

Velocity Trend Analysis:

Sprint | Velocity | Trend
-------|----------|-------
1      | 18       | Baseline
2      | 20       | ↑ Increasing
3      | 22       | ↑ Increasing
4      | 21       | → Stable
5      | 23       | ↑ Increasing

Conclusion: Team is improving, velocity trending up
Average: 20.8 points
Use 21 points for planning

Improving Velocity

1. Better Estimation

Problems:

1. Inconsistent Sizing

• Same story, different sizes
• No calibration
• Unreliable estimates
• Poor planning

2. No Calibration

• No reference stories
• No team agreement
• Inconsistent scale
• Hard to compare

3. Pressure to Inflate

• Pressure to show progress
• Gaming the system
• Inflated estimates
• Meaningless velocity

Solutions:

1. Story Point Calibration

• Establish reference stories
• Team agrees on scale
• Regular calibration sessions
• Consistent sizing

Reference Story Example:

Reference Story: "User can login" = 3 points

Team agrees:
- Simpler than login = 1-2 points
- Similar to login = 3 points
- More complex = 5-8 points
- Much more complex = 13+ points

2. Regular Review

• Review estimates vs actual
• Learn from differences
• Calibrate regularly
• Improve accuracy

3. Team Agreement

• Team estimates together
• Discuss differences
• Reach consensus
• Shared understanding

2. Remove Blockers

Impact: Blockers reduce velocity → Less work completed → Lower velocity

How Blockers Affect Velocity:

Sprint without blockers:
- Completed: 20 points
- Velocity: 20 points

Sprint with blockers:
- Blocked for 2 days
- Completed: 12 points
- Velocity: 12 points
- Impact: 40% reduction

How to Remove Blockers:

1. Identify Quickly

• Daily standup focus
• Blocker board
• Team awareness
• Immediate escalation

2. Escalate Fast

• Don’t wait
• Escalate immediately
• Assign owners
• Track resolution

3. Track Blockers

• Blocker age
• Resolution time
• Pattern identification
• Root cause analysis

4. Remove Root Causes

• Why did blocker happen?
• How to prevent?
• Process changes
• Team learning

Example:

Blocker Tracking:

Blocker | Age | Impact | Status
--------|-----|--------|--------
API access | 2 days | High | In progress
Design approval | 1 day | Medium | Waiting
Dependency | 3 days | High | Escalated

Action: Escalate all blockers, assign owners
Target: Resolve within 4 hours

3. Smaller Stories

Benefits:

• Faster completion
• More predictable
• Better flow
• Earlier feedback

Impact on Velocity:

Large Stories (8+ points):
- Take longer to complete
- Higher risk
- Less predictable
- Lower velocity

Small Stories (3-5 points):
- Complete faster
- Lower risk
- More predictable
- Higher velocity

How to Break Down:

1. By Feature Slice

Large: "Build user dashboard" (13 points)
Break into:
- Show user profile (3 points)
- Display recent activity (5 points)
- Show notifications (3 points)
- User settings (2 points)

2. By User Journey

Large: "Complete checkout" (13 points)
Break into:
- Add items to cart (3 points)
- Enter shipping info (5 points)
- Process payment (5 points)

3. By Technical Layer

Large: "Add search" (13 points)
Break into:
- Backend API (5 points)
- Frontend UI (5 points)
- Results display (3 points)

4. Technical Excellence

Practices:

1. Good Code Quality

• Clean code
• Well-structured
• Maintainable
• Documented

2. Automated Testing

• Unit tests
• Integration tests
• E2E tests
• Fast feedback

3. CI/CD

• Automated builds
• Automated deployment
• Fast feedback
• Lower risk

4. Refactoring

• Regular refactoring
• Technical debt management
• Code quality
• Maintainability

Impact:

• Less rework
• Faster delivery
• Higher quality
• Sustainable pace

Example:

Before Technical Excellence:
- Rework: 30% of time
- Bugs: High
- Velocity: 15 points

After Technical Excellence:
- Rework: 10% of time
- Bugs: Low
- Velocity: 22 points

Improvement: 47% increase in velocity

5. Team Stability

Impact: Team changes affect velocity → New members need time → Velocity decreases temporarily

How Team Changes Affect Velocity:

Stable Team (5 members):
- Velocity: 20 points
- Consistent delivery

Team Change (1 new member):
- Sprint 1: 15 points (learning)
- Sprint 2: 18 points (improving)
- Sprint 3: 20 points (back to normal)

Impact: 2-3 sprints to recover

How to Maintain Stability:

1. Keep Teams Together

• Don’t shuffle teams
• Maintain team composition
• Build relationships
• Develop team dynamics

2. Onboard Well

• Structured onboarding
• Pair programming
• Knowledge sharing
• Support new members

3. Knowledge Sharing

• Documentation
• Code reviews
• Pair programming
• Tech talks

4. Pair Programming

• Share knowledge
• Faster learning
• Better quality
• Team building

Common Mistakes

1. Comparing Teams

The Problem: Comparing velocity across teams → Creates unhealthy competition, wrong incentives

Why It Fails:

• Velocity is team-specific
• Different estimation scales
• Different contexts
• Not comparable

The Solution:

• Don’t compare teams
• Focus on trends within team
• Use for planning only
• Improve own velocity

Example:

❌ Bad: "Team A's velocity is 30, Team B's is 20. Team A is better."

✅ Good: "Team A's velocity increased from 25 to 30. Great improvement!"

2. Using as Performance Metric

The Problem: Using velocity to evaluate performance → Creates pressure, gaming, toxic culture

Why It Fails:

• Creates wrong incentives
• Leads to gaming
• Hurts quality
• Breaks trust

The Solution:

• Use for planning only
• Don’t tie to performance
• Focus on outcomes
• Trust your team

Example:

❌ Bad: "Your velocity is low. You need to improve."

✅ Good: "Let's look at what's affecting velocity and how we can improve our process."

3. Focusing Only on Velocity

The Problem: Focusing only on velocity → Ignores quality, value, team health

Why It Fails:

• Velocity without quality = waste
• Velocity without value = pointless
• Hurts team health
• Wrong focus

The Solution:

• Balance with quality metrics
• Focus on value delivered
• Consider team health
• Holistic view

Example:

❌ Bad: "Velocity increased from 20 to 25. Great!" (But quality decreased)

✅ Good: "Velocity is 22, quality is high, team is happy. Perfect balance."

4. Not Accounting for Context

The Problem: Not considering context → Misleading velocity, poor planning

Why It Fails:

• Velocity varies with context
• Holidays affect capacity
• Team changes affect velocity
• Different story types

The Solution:

• Consider holidays
• Account for team changes
• Adjust for complexity
• Use context in planning

Example:

Sprint with holidays:
- Normal velocity: 20 points
- Holiday week: 10 working days instead of 10
- Adjusted capacity: 15 points
- Plan accordingly

5. Changing Estimation Mid-Sprint

The Problem: Changing estimates during sprint → Invalidates velocity, unreliable data

Why It Fails:

• Velocity becomes meaningless
• Can’t track trends
• Unreliable for planning
• Breaks trust

The Solution:

• Estimate once (at planning)
• Track completion (not re-estimation)
• Learn for next sprint
• Don’t change mid-sprint

Example:

❌ Bad: "This story is taking longer. Let's change it from 5 to 8 points."

✅ Good: "This story took longer than estimated. Let's learn from this for next sprint."

Velocity Dashboard

What to Track

1. Velocity Trend

• Last 5-10 sprints
• Trend line
• Moving average
• Annotations for context

2. Story Point Distribution

• How many stories per sprint?
• Average story size?
• Distribution of sizes?
• Patterns?

3. Completion Rate

• What % of planned stories completed?
• Are we over/under committing?
• How accurate are estimates?

4. Context Factors

• Team changes
• Holidays
• Process changes
• External factors

Example Dashboard:

Velocity Trend (Last 6 Sprints):
Sprint | Velocity | Notes
-------|----------|------------------
1      | 18       | Baseline
2      | 20       | New team member
3      | 22       | Process improved
4      | 21       | Holiday week
5      | 23       | Stable team
6      | 22       | Stable

Average: 21 points
Trend: Increasing
Use 21 points for planning

The Bottom Line

Effective velocity use:

• Measure consistently: Same method, same team
• Use for planning: Predict capacity, not judge performance
• Track trends: Identify patterns, not absolute numbers
• Don’t compare: Team-specific metric, not competition
• Balance: With quality and value metrics

Velocity is a tool for planning, not a performance metric. Use it wisely to improve predictability and delivery, not to create pressure or competition.

Key Takeaways:

1. Velocity is team-specific (don’t compare teams)
2. Use for planning (not performance evaluation)
3. Track trends (not absolute numbers)
4. Account for context (holidays, changes)
5. Balance with quality (velocity without quality is waste)
6. Improve through process (not pressure)

Need help with velocity tracking? Contact 8MB Tech for Agile coaching and metrics consulting.