Team Velocity Tracking and Improvement | Planning
Use velocity for planning, not performance metrics. GitScrum tracks sprint velocity, averages trends, and helps forecast delivery without gaming estimates.
9 min read
Velocity is a planning tool, not a productivity metric. GitScrum tracks team velocity automatically and helps teams use it for realistic sprint planning.
Understanding Velocity
What Velocity Is
VELOCITY DEFINED:
┌─────────────────────────────────────────────────────────────┐
│ │
│ VELOCITY = Work completed in a sprint │
│ │
│ Sprint 21: 38 points completed │
│ Sprint 22: 42 points completed │
│ Sprint 23: 40 points completed │
│ Sprint 24: 44 points completed │
│ ───────────────────────────── │
│ Average velocity: 41 points │
│ │
│ ═══════════════════════════════════════════════════════════ │
│ │
│ VELOCITY IS: │
│ ✅ A planning tool │
│ ✅ Specific to one team │
│ ✅ An average over time │
│ ✅ Input for sprint planning │
│ ✅ A way to forecast delivery │
│ │
│ VELOCITY IS NOT: │
│ ❌ A productivity metric │
│ ❌ Comparable between teams │
│ ❌ A target to maximize │
│ ❌ A performance indicator │
│ ❌ Something to gamify │
│ │
│ "Velocity is a measure of capacity, not performance" │
└─────────────────────────────────────────────────────────────┘
Why Teams Misuse Velocity
VELOCITY MISUSE PATTERNS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ ❌ "INCREASE VELOCITY BY 10%" │
│ │
│ What happens: │
│ • Team inflates estimates │
│ • "5 points is now 8 points" │
│ • Velocity goes up, output stays same │
│ • Gaming, not improvement │
│ │
│ ❌ "COMPARE TEAM A VS TEAM B" │
│ │
│ What happens: │
│ • Teams estimate differently │
│ • Context is different │
│ • Creates competition, not collaboration │
│ • Meaningless comparison │
│ │
│ ❌ "VELOCITY MUST ALWAYS INCREASE" │
│ │
│ What happens: │
│ • Unsustainable pace │
│ • Quality sacrificed │
│ • Burnout │
│ • Technical debt grows │
│ │
│ ❌ "LOW VELOCITY = BAD TEAM" │
│ │
│ What happens: │
│ • Ignores context │
│ • Punishes teams with hard problems │
│ • Discourages accurate estimation │
│ │
│ THE GOAL: Stable, predictable velocity │
└─────────────────────────────────────────────────────────────┘
Measuring Velocity
Calculating Velocity
VELOCITY CALCULATION:
┌─────────────────────────────────────────────────────────────┐
│ │
│ RULE: Only count DONE stories │
│ │
│ Sprint 24 Planned: │
│ ├── Story A: 8 points → Done ✅ │
│ ├── Story B: 5 points → Done ✅ │
│ ├── Story C: 8 points → Done ✅ │
│ ├── Story D: 5 points → 80% done ❌ │
│ └── Story E: 3 points → Done ✅ │
│ │
│ VELOCITY = 8 + 5 + 8 + 3 = 24 points │
│ │
│ Story D doesn't count (not done) │
│ → Carries to next sprint │
│ │
│ ═══════════════════════════════════════════════════════════ │
│ │
│ AVERAGE VELOCITY: │
│ │
│ Use last 3-5 sprints: │
│ Sprint 21: 38 │
│ Sprint 22: 42 │
│ Sprint 23: 40 │
│ Sprint 24: 24 (holiday week) │
│ Sprint 25: 44 │
│ │
│ Average: (38+42+40+24+44)/5 = 37.6 │
│ │
│ CONSIDER: │
│ • Exclude anomalies (holidays, incidents) │
│ • More sprints = more stable average │
│ • Recent sprints more relevant │
└─────────────────────────────────────────────────────────────┘
GitScrum Velocity View
VELOCITY TRACKING IN GITSCRUM:
┌─────────────────────────────────────────────────────────────┐
│ Team Velocity │
├─────────────────────────────────────────────────────────────┤
│ │
│ VELOCITY CHART: │
│ │
│ 50│ ┌──┐ │
│ 45│ ┌──┐ │ │ ┌──┐ │
│ 40│ ┌──┤ │ │ │ │ │ ┌──┐ │
│ 35│ │ │ │ │ │ │ │ │ │ │
│ 30│ │ │ │ │ │ │ │ │ │ │
│ 25│ │ │ │ │ ├─┤ │ │ │ │
│ 20│ │ │ │ │ │ │ │ │ │ │
│ └─┴──┴──┴─┴──┴─┴──┴─┴──┴─ │
│ S21 S22 S23 S24 S25 │
│ ↑ │
│ (holiday) │
│ │
│ AVERAGE: 41 points │
│ TREND: Stable (±10%) │
│ LAST SPRINT: 44 points │
│ │
│ PLANNING GUIDE: │
│ Comfortable range: 38-44 points │
│ Don't exceed: 48 points │
│ │
│ NOTES: │
│ Sprint 24: Holiday week (lower capacity) │
└─────────────────────────────────────────────────────────────┘
Using Velocity
Sprint Planning
VELOCITY-BASED PLANNING:
┌─────────────────────────────────────────────────────────────┐
│ │
│ AVERAGE VELOCITY: 41 points │
│ │
│ CAPACITY ADJUSTMENTS: │
│ • Full team: 100% → 41 points │
│ • 1 person on vacation: -20% → 33 points │
│ • New team member: +10% → 45 points (ramping) │
│ • Holiday week: -40% → 25 points │
│ │
│ SPRINT 26 PLANNING: │
│ │
│ Capacity: Full team (41 points available) │
│ │
│ Selected: │
│ ├── Story A: 8 points │
│ ├── Story B: 5 points │
│ ├── Story C: 13 points │
│ ├── Story D: 8 points │
│ └── Story E: 5 points │
│ ───────────────────── │
│ Total: 39 points │
│ │
│ ✅ Within velocity (39 < 41) │
│ ✅ Buffer for unknowns (2 points) │
│ │
│ RULES: │
│ • Never plan above velocity │
│ • Leave 5-10% buffer │
│ • Adjust for known capacity changes │
└─────────────────────────────────────────────────────────────┘
Forecasting
USING VELOCITY FOR FORECASTING:
┌─────────────────────────────────────────────────────────────┐
│ │
│ QUESTION: "When will the feature be done?" │
│ │
│ REMAINING WORK: 120 points │
│ VELOCITY: 41 points/sprint │
│ SPRINT LENGTH: 2 weeks │
│ │
│ CALCULATION: │
│ 120 points ÷ 41 points/sprint = ~3 sprints │
│ │
│ FORECAST: │
│ Optimistic (50 pts/sprint): 2.4 sprints (~5 weeks) │
│ Expected (41 pts/sprint): 2.9 sprints (~6 weeks) │
│ Pessimistic (32 pts/sprint): 3.8 sprints (~8 weeks) │
│ │
│ ANSWER: │
│ "We expect completion in 6-8 weeks" │
│ │
│ ═══════════════════════════════════════════════════════════ │
│ │
│ IMPORTANT CAVEATS: │
│ │
│ • Estimates may be wrong │
│ • Scope may change │
│ • New work may be added │
│ • Team composition may change │
│ │
│ COMMUNICATE UNCERTAINTY: │
│ "Based on current velocity and scope..." │
│ "This assumes no major changes..." │
│ "We'll have better visibility after Sprint X..." │
└─────────────────────────────────────────────────────────────┘
Improving Velocity
Healthy Improvement
SUSTAINABLE VELOCITY IMPROVEMENT:
┌─────────────────────────────────────────────────────────────┐
│ │
│ GOOD WAYS TO IMPROVE VELOCITY: │
│ │
│ REMOVE IMPEDIMENTS: │
│ • Faster environments │
│ • Better tools │
│ • Clearer requirements │
│ • Faster feedback loops │
│ │
│ REDUCE WASTE: │
│ • Fewer meetings │
│ • Less context switching │
│ • Shorter code reviews │
│ • Faster deployments │
│ │
│ IMPROVE QUALITY: │
│ • Fewer bugs (less rework) │
│ • Better tests (less debugging) │
│ • Cleaner code (faster changes) │
│ │
│ BETTER PRACTICES: │
│ • Smaller stories (faster flow) │
│ • Clearer acceptance criteria │
│ • More pairing (less stuck time) │
│ │
│ BAD WAYS TO "IMPROVE" VELOCITY: │
│ │
│ ❌ Work more hours │
│ ❌ Skip testing │
│ ❌ Inflate estimates │
│ ❌ Reduce quality │
│ ❌ Pressure the team │
│ │
│ "Sustainable pace produces sustainable velocity" │
└─────────────────────────────────────────────────────────────┘
Velocity Patterns
WHAT VELOCITY TELLS YOU:
┌─────────────────────────────────────────────────────────────┐
│ │
│ STABLE VELOCITY: │
│ [████ ████ ████ ████] │
│ Team is predictable │
│ Good estimation calibration │
│ This is the goal! │
│ │
│ DECLINING VELOCITY: │
│ [████ ███░ ██░░ █░░░] │
│ Something is wrong │
│ Investigate: Burnout? Blockers? Technical debt? │
│ Address root cause, not symptoms │
│ │
│ ERRATIC VELOCITY: │
│ [██░░ ████ █░░░ ████] │
│ Poor estimation │
│ Unpredictable work │
│ Work on consistency │
│ │
│ INCREASING VELOCITY: │
│ [██░░ ███░ ████ ████] │
│ Could be good (team improving) │
│ Could be bad (inflation, unsustainable) │
│ Verify it's genuine │
│ │
│ SPIKE THEN DROP: │
│ [████ ████ ████████ ██░░] │
│ Crunch followed by recovery │
│ Unsustainable - avoid this pattern │
└─────────────────────────────────────────────────────────────┘
Team Conversations
Retrospective Discussion
VELOCITY IN RETROSPECTIVES:
┌─────────────────────────────────────────────────────────────┐
│ │
│ HEALTHY DISCUSSION: │
│ │
│ "Our velocity dropped this sprint. What happened?" │
│ │
│ → Discuss blockers │
│ → Identify impediments │
│ → Plan improvements │
│ → No blame │
│ │
│ UNHEALTHY DISCUSSION: │
│ │
│ "Velocity is too low. We need to work harder." │
│ │
│ → Pressure without understanding │
│ → Leads to gaming or burnout │
│ → Doesn't address real issues │
│ │
│ ═══════════════════════════════════════════════════════════ │
│ │
│ GOOD QUESTIONS: │
│ │
│ "What slowed us down this sprint?" │
│ "What would help us work more smoothly?" │
│ "Are our estimates still calibrated?" │
│ "Is our work sustainably sized?" │
│ │
│ ACTIONS MIGHT BE: │
│ │
│ • Remove a recurring blocker │
│ • Improve a slow process │
│ • Get better tools │
│ • Clarify requirements earlier │
│ • Reduce meeting overhead │
└─────────────────────────────────────────────────────────────┘