Sprint Planning Accuracy | Velocity-Based Commitment
Hit 90%+ sprint completion with velocity-based planning, task decomposition, and buffer strategies. Track estimated vs actual to calibrate over time.
7 min read
Sprint planning accuracy determines whether you deliver what you committed or constantly miss targets. Accurate planning builds trust with stakeholders, enables reliable forecasting, and creates sustainable pace. It requires data, discipline, and continuous calibration.
Planning Accuracy Problems
| Problem | Cause | Solution |
|---|---|---|
| Over-commit | Optimism bias | Use historical velocity |
| Unfinished work | Scope creep | Protect commitment |
| Constant surprises | Unknown work | Add buffer |
| Inaccurate estimates | No feedback loop | Track actual vs. estimate |
Estimation Improvement
Using Historical Data
VELOCITY-BASED PLANNING
═══════════════════════
HISTORICAL VELOCITY:
─────────────────────────────────────
Sprint Committed Completed Rate
────────────────────────────────────
20 35 32 91%
21 38 29 76%
22 32 30 94%
23 34 33 97%
24 36 31 86%
25 33 32 97%
─────────────────────────────────────
Average velocity: 31 points
Standard deviation: 1.5 points
Reliable capacity: 30 points (avg - 1 std)
NEXT SPRINT PLANNING:
├── Don't commit > 30 points
├── If uncertain items, commit less
├── Leave room for surprises
└── 30 points = realistic commitment
VELOCITY TREND:
├── Stable: Use average
├── Improving: Use recent average (last 3)
├── Declining: Investigate root cause
└── Erratic: Use lowest recent
Task Decomposition
BREAKING DOWN WORK
══════════════════
BEFORE:
─────────────────────────────────────
User Story: "User login"
Estimate: 13 points (large, vague)
Accuracy: Poor (too big to estimate)
AFTER (decomposed):
─────────────────────────────────────
"Login - UI form" 3 pts
"Login - API endpoint" 3 pts
"Login - validation" 2 pts
"Login - error handling" 2 pts
"Login - tests" 2 pts
"Login - integration" 1 pt
─────────────────────────────────────
Total: 13 points (same, but accurate)
WHY BETTER:
├── Each piece is understood
├── Hidden complexity exposed
├── Can verify each part
├── Better tracking
└── Easier to parallelize
DECOMPOSITION RULES:
├── No item > 5 points
├── Each item ships independently
├── Clear acceptance criteria each
├── Estimable in < 2 minutes
└── Complete in 1-2 days
Estimation Calibration
ESTIMATE CALIBRATION
════════════════════
TRACK FOR EACH TASK:
├── Estimate (points or hours)
├── Actual time spent
├── Calculate ratio
EXAMPLE TRACKING:
─────────────────────────────────────
Task Estimate Actual Ratio
─────────────────────────────────────
GS-123 3 pts 4.5 hrs 1.5x
GS-124 2 pts 2 hrs 1.0x
GS-125 5 pts 9 hrs 1.8x
GS-126 3 pts 3 hrs 1.0x
─────────────────────────────────────
Average ratio: 1.3x
CALIBRATION:
├── Team underestimates by 1.3x
├── Apply factor to future estimates
├── Or acknowledge in capacity planning
└── Improve over time
FEEDBACK LOOP:
1. Estimate before work
2. Track actual during work
3. Compare at sprint end
4. Discuss in retro
5. Adjust technique
6. Repeat
Capacity Planning
Realistic Capacity
TRUE CAPACITY CALCULATION
═════════════════════════
STARTING POINT:
├── 5 developers
├── 10 working days (2-week sprint)
├── 8 hours/day
└── Total: 400 hours (theoretical)
SUBTRACT OVERHEAD:
─────────────────────────────────────
Meetings per developer: -16h
├── Daily standup: 5h (15min × 10d × 2)
├── Sprint planning: 2h
├── Sprint review: 1h
├── Retrospective: 1h
├── 1:1 meetings: 2h
├── Other meetings: 5h
Per developer non-coding: -8h
├── Email/Slack: 5h
├── Context switching: 3h
Total overhead per person: 24h
For 5 developers: 120h
─────────────────────────────────────
Productive capacity: 400 - 120 = 280h
FURTHER ADJUST:
├── PTO this sprint: -16h (1 person, 2 days)
├── Holidays: 0
├── Support rotation: -8h
└── Adjusted: 256h
PLAN AT 80%:
256h × 0.8 = 205h plannable
= ~41h per developer
= ~5 days actual coding
MUCH LESS THAN 8h × 10 DAYS!
Buffer for Unknowns
BUILDING IN BUFFER
══════════════════
BUFFER TYPES:
─────────────────────────────────────
1. ESTIMATION BUFFER (20%)
├── Estimates are optimistic
├── Hidden complexity
└── Apply to each estimate
2. SPRINT BUFFER (10-15%)
├── Unexpected work
├── Production issues
├── Urgent requests
└── Don't fill to 100%
3. RISK BUFFER (variable)
├── New technology: +20%
├── Unclear requirements: +30%
├── External dependency: +20%
└── New team member: +15%
APPLICATION:
─────────────────────────────────────
Capacity: 40 points
Committed work: 32 points (80%)
├── Known work: 25 points
├── Estimation buffer: 5 points (20%)
├── Sprint buffer: 2 points
Remaining: 8 points (20%)
├── For urgent unplanned work
├── For carrying forward if needed
└── Not committed, aspirational
Sprint Protection
Scope Management
PROTECTING SPRINT SCOPE
═══════════════════════
COMMITMENT = CONTRACT
─────────────────────────────────────
At sprint planning:
├── Team commits to specific items
├── Stakeholders accept commitment
├── Changes require negotiation
└── Not a one-way addition
CHANGE PROCESS:
─────────────────────────────────────
New request during sprint:
1. "Is it urgent? (Production down, etc.)"
├── If yes: Add, something else drops
└── If no: Goes to next sprint
2. "If urgent, what gets removed?"
├── Equal or greater scope
├── Requester decides priority
└── No free additions
3. Document the swap
├── Added: GS-789 (urgent bug)
├── Removed: GS-234 (moved to next)
└── Reason: Customer-facing issue
SAYING NO:
├── "Sprint is committed. Next sprint?"
├── "We can add this if X drops."
├── "Let's discuss in planning."
└── Protect the team
Carryover Management
HANDLING CARRYOVER
══════════════════
IDEAL: No carryover
REALITY: Sometimes happens
IF CARRYOVER OCCURS:
─────────────────────────────────────
1. ANALYZE IN RETRO
├── Why wasn't it completed?
├── Estimate wrong?
├── Blocked?
├── Scope crept?
└── Understand root cause
2. DECIDE FATE
├── Must complete: Carry forward
├── Can wait: Reprioritize
├── Obsolete: Close/archive
└── Don't auto-carry everything
3. ADJUST NEXT SPRINT
├── Carried work is first priority
├── Reduce new commitment
├── Account for partial work done
└── Don't overload
TRACKING:
├── Carryover rate per sprint
├── Trend: Should decrease over time
├── Target: < 10% of commitment
└── Action if consistently high
GitScrum for Planning
Planning Features
GITSCRUM PLANNING TOOLS
═══════════════════════
VELOCITY DASHBOARD:
├── Last 6 sprints velocity
├── Trend visualization
├── Recommended commitment
└── Capacity calculator
SPRINT PLANNING VIEW:
┌─────────────────────────────────────────────────────────┐
│ Sprint 26 Planning │
├─────────────────────────────────────────────────────────┤
│ CAPACITY │
│ Average velocity: 31 pts │
│ Team availability: 90% (PTO adjustment) │
│ Recommended: 28 pts │
│ │
│ COMMITTED: 26 pts (93% of recommended) │
│ ──────────────────────────────────────────────── │
│ [GS-300] Login redesign 8 pts │
│ [GS-301] API performance 5 pts │
│ [GS-302] Bug fixes 5 pts │
│ [GS-303] Dashboard update 5 pts │
│ [GS-304] Documentation 3 pts │
│ │
│ STATUS: ✓ Within capacity │
└─────────────────────────────────────────────────────────┘
ESTIMATION ACCURACY:
├── Track estimate vs. actual
├── Calibration factor
├── Team-level trends
└── Individual insights (optional)
Best Practices
For Sprint Planning
Anti-Patterns
PLANNING MISTAKES:
✗ Ignoring historical velocity
✗ 100% capacity planning
✗ Large vague stories
✗ No buffer for unknowns
✗ Adding without removing
✗ Not tracking accuracy
✗ Same mistakes each sprint
✗ Optimism over data