Velocity Tracking and Improvement | Planning Guide
Measure and improve team velocity for predictable planning. GitScrum tracks sprint trends, commitment vs completed, and sustainable improvement patterns.
7 min read
Velocity measures how much work a team completes per sprint. It's a planning tool, not a performance metric. Understanding velocity helps teams commit to achievable work and stakeholders set realistic expectations. Improving velocity means removing friction, not working harder.
Understanding Velocity
What Velocity Is
VELOCITY FUNDAMENTALS
═════════════════════
DEFINITION:
─────────────────────────────────────
Velocity = Story Points completed per sprint
Example:
├── Sprint 1: 34 points
├── Sprint 2: 28 points
├── Sprint 3: 32 points
├── Sprint 4: 30 points
└── Average velocity: 31 points
WHAT VELOCITY IS:
─────────────────────────────────────
✓ Planning tool ("Can we commit to this?")
✓ Capacity indicator ("How much can we do?")
✓ Trend tracker ("Are we improving?")
✓ Team-specific measure
✓ Relative measure
WHAT VELOCITY IS NOT:
─────────────────────────────────────
✗ Performance metric
✗ Productivity measure
✗ Comparable between teams
✗ Absolute measure
✗ Target to maximize
✗ Individual metric
VELOCITY RANGE:
─────────────────────────────────────
┌─────────────────────────────────────────────────────────┐
│ Team Alpha Velocity │
├─────────────────────────────────────────────────────────┤
│ │
│ 45 ┤ │
│ │ ◆ High: 38 │
│ 35 ┤ ◆ ◆──────────── Average: 31 │
│ │ ◆ ◆ ◆ │
│ 25 ┤ ◆ ◆ ◆ Low: 24 │
│ │ │
│ 15 ┤ │
│ └──────────────────────────────────────────────────│
│ S1 S2 S3 S4 S5 S6 S7 S8 S9 S10 │
│ │
│ Average: 31 pts | Range: 24-38 | Variance: ±22% │
└─────────────────────────────────────────────────────────┘
Use RANGE for planning, not just average.
Expect variance—it's normal.
Using Velocity
VELOCITY FOR PLANNING
═════════════════════
SPRINT COMMITMENT:
─────────────────────────────────────
Step 1: Know your velocity
├── Last 3 sprints: 32, 28, 34
├── Average: 31 points
├── Range: 28-34
└── Commit: 28-31 points (conservative)
Step 2: Account for factors
├── Holiday week? Reduce 20%
├── Team member out? Reduce proportionally
├── New team members? Reduce for onboarding
└── Adjusted: 25 points
Step 3: Pull from backlog
├── Pull highest priority items
├── Until you hit capacity
├── Leave buffer for surprises
└── Don't exceed adjusted velocity
LONG-RANGE PLANNING:
─────────────────────────────────────
Release planning example:
├── Remaining backlog: 180 points
├── Average velocity: 30 points
├── Sprints needed: 180 ÷ 30 = 6 sprints
├── Buffer (10%): +1 sprint
├── Estimate: 7 sprints (14 weeks)
└── Communicate as range, not promise
Present as:
"Based on current velocity, we estimate
6-8 sprints. We'll update as we learn more."
Tracking Velocity
Measurement
VELOCITY TRACKING
═════════════════
WHAT COUNTS:
─────────────────────────────────────
Count as complete:
├── Meets Definition of Done
├── Potentially shippable
├── Accepted by PO
└── Full story points
Don't count:
├── Partially done (0 points, not fraction)
├── "Almost done"
├── Tested but not deployed (if deploy = done)
├── Carried over to next sprint
└── Scope added mid-sprint
TRACKING IN GITSCRUM:
─────────────────────────────────────
Sprint → Close Sprint → Velocity recorded
Dashboard shows:
├── Velocity per sprint
├── Trend over time
├── Average velocity
├── Variance
└── Commitment vs. completed
VELOCITY TREND:
─────────────────────────────────────
┌─────────────────────────────────────────────────────────┐
│ Velocity Trend (12 sprints) │
├─────────────────────────────────────────────────────────┤
│ │
│ 40 ┤ ◆ ◆ │
│ │ ◆ ◆ │
│ 30 ┤ ◆ ◆ ◆ ◆ ◆ │
│ │ ◆ ◆ │
│ 20 ┤ ◆ ◆ │
│ │ │
│ 10 ┤ │
│ └──────────────────────────────────────────────────│
│ Formation → Stabilizing → Improving → │
│ │
│ ↗ Trend: Improving (+2 pts/sprint) │
└─────────────────────────────────────────────────────────┘
Early sprints: Low (learning)
Middle: Stabilizing
Later: May improve as team matures
Improving Velocity
Legitimate Improvements
HOW TO IMPROVE VELOCITY
═══════════════════════
SUSTAINABLE IMPROVEMENT:
─────────────────────────────────────
Velocity improves through:
1. REMOVE BLOCKERS
├── Faster code review turnaround
├── Quicker stakeholder decisions
├── Better tooling
├── Clearer requirements
└── Visible in retros
2. REDUCE WASTE
├── Fewer unnecessary meetings
├── Less context switching
├── Reduced rework
├── Smaller batch sizes
└── Better definition of ready
3. IMPROVE PROCESS
├── Better testing practices
├── CI/CD improvements
├── More effective ceremonies
├── Clearer Definition of Done
└── Collaborative refinement
4. REDUCE TECHNICAL DEBT
├── Easier codebase = faster work
├── Fewer bugs = less rework
├── Better architecture = faster features
└── Investment pays off over time
5. TEAM GROWTH
├── More experience
├── Better collaboration
├── Skills development
├── Domain knowledge
└── Natural over time
NOT SUSTAINABLE:
─────────────────────────────────────
✗ Working overtime
✗ Cutting quality
✗ Skipping tests
✗ Reducing estimates to "get more done"
✗ Pressure to hit targets
Finding Improvement Opportunities
VELOCITY IMPROVEMENT ANALYSIS
═════════════════════════════
USE RETROSPECTIVES:
─────────────────────────────────────
Ask:
"What slowed us down this sprint?"
"Where did we wait?"
"What would we do differently?"
Common answers that improve velocity:
├── "Waiting for code review"
│ → Implement review SLA
│
├── "Requirements were unclear"
│ → Improve refinement
│
├── "Deployment took forever"
│ → Invest in CI/CD
│
├── "Meetings fragmented my day"
│ → Meeting-free blocks
│
└── "Bugs in legacy code"
→ Address technical debt
USE METRICS:
─────────────────────────────────────
Cycle time by stage:
├── Development: 2 days (expected)
├── Code Review: 3 days (too long!)
├── Testing: 1 day (expected)
├── Deploy: 2 days (too long!)
└── Total: 8 days
Target improvements where wait is longest.
WIP ANALYSIS:
─────────────────────────────────────
High WIP = Low throughput
├── Too much in progress
├── Context switching overhead
├── Nothing finishing
└── Reduce WIP limits
Velocity Antipatterns
What to Avoid
VELOCITY ANTIPATTERNS
═════════════════════
USING VELOCITY AS TARGET:
─────────────────────────────────────
"Your velocity needs to be 40 by next quarter."
Result:
├── Inflated estimates
├── Cut quality
├── Gaming metrics
├── Trust destroyed
├── Real velocity hidden
└── Worse outcomes
COMPARING TEAM VELOCITIES:
─────────────────────────────────────
"Team A does 50 points, why can't you?"
Problem:
├── Different estimation scales
├── Different work types
├── Different team sizes
├── Points are relative, not absolute
└── Comparison is meaningless
FOCUS INSTEAD ON:
├── Each team's trend (improving?)
├── Predictability (consistent?)
├── Outcomes (value delivered?)
└── Team health (sustainable?)
PARTIAL CREDIT:
─────────────────────────────────────
"Story 80% done, count 80% of points."
Problem:
├── 80% done often means 50% work left
├── Inflates velocity artificially
├── Encourages partial completion
├── Hiding incomplete work
└── Unpredictable
Rule: Done or not done.
Not done = 0 points this sprint.
GitScrum Velocity
Velocity Features
GITSCRUM VELOCITY TOOLS
═══════════════════════
VELOCITY CHART:
─────────────────────────────────────
Reports → Velocity
Shows:
├── Committed vs. completed per sprint
├── Running average
├── Trend line
├── Variance indicator
└── Export for reporting
SPRINT PLANNING:
─────────────────────────────────────
While adding to sprint:
├── Shows running points total
├── Compares to average velocity
├── Warning if exceeding capacity
├── Suggests realistic commitment
└── Historical context
RELEASE PLANNING:
─────────────────────────────────────
Roadmap → Release
Based on velocity:
├── Projected completion date
├── Confidence range
├── What fits in release
├── Trade-off visibility
└── Stakeholder planning
VELOCITY SETTINGS:
─────────────────────────────────────
Configure:
├── Sprints for average (3-5 typical)
├── Show/hide variance
├── Include specific sprints
├── Export data
└── Dashboard widgets
Best Practices
For Velocity
Anti-Patterns
VELOCITY MISTAKES:
✗ Velocity as performance metric
✗ Comparing team velocities
✗ "Increase velocity 20%"
✗ Partial point counting
✗ Overtime to hit target
✗ Cutting quality for speed
✗ Inflating estimates
✗ Ignoring variance