Developer Task Estimation | Velocity Data
Improve sprint estimation with story points and historical velocity tracking. GitScrum helps teams plan more reliably and set realistic expectations.
10 min read
Task estimation remains one of software development's hardest challenges. GitScrum helps teams estimate more accurately by providing historical velocity data, story point tracking, and estimation patterns that improve predictability over time based on actual team performance.
The Estimation Problem
Poor estimates cause cascading issues:
- Missed deadlines — Overcommitted sprints fail consistently
- Burned out teams — Constantly working overtime to meet estimates
- Stakeholder frustration — Promises repeatedly broken
- Planning paralysis — Fear of committing to any timeline
- Scope creep disguised — "Small" tasks balloon unexpectedly
- Lost credibility — Team estimates become meaningless
GitScrum Estimation Solution
Build estimation accuracy through data:
Key Features
| Feature | Estimation Use |
|---|---|
| Story points | Relative sizing that improves over time |
| Velocity tracking | Historical delivery patterns |
| Sprint analytics | Actual vs. planned comparison |
| Task history | Reference similar past work |
| Time tracking | Calibrate estimates with reality |
Story Point Estimation
Understanding Relative Sizing
Story Point Scale (Fibonacci):
1 point — Trivial change, < 2 hours
Example: Fix typo in UI, update config value
2 points — Simple task, clear implementation
Example: Add form validation, update API endpoint
3 points — Moderate complexity, some unknowns
Example: New component with standard patterns
5 points — Significant work, multiple parts
Example: Feature with frontend + backend + tests
8 points — Complex feature, many unknowns
Example: New integration, significant refactoring
13 points — Very complex, should consider splitting
Example: Major new capability, architectural change
21+ points — Too large, must split before starting
Example: Epic-level work, needs decomposition
Estimation Session in GitScrum
Sprint Planning: Estimation Phase
Task: #234 "Implement user dashboard"
Team Estimates (hidden until reveal):
├── @alice: 8 points
├── @bob: 5 points
├── @carol: 13 points
└── @dave: 8 points
Reveal Discussion:
├── Lowest (Bob, 5): "We have similar components to reuse"
├── Highest (Carol, 13): "What about the new chart library?"
└── Discussion: "Good point - chart integration adds complexity"
Re-estimate:
├── @alice: 8 points
├── @bob: 8 points
├── @carol: 8 points
└── @dave: 8 points
Final: 8 points ✓
Historical Velocity Analysis
Team Velocity Dashboard
Team Velocity: Last 6 Sprints
━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Sprint │ Committed │ Completed │ Rate
──────────┼───────────┼───────────┼──────
Sprint 18 │ 45 pts │ 42 pts │ 93%
Sprint 17 │ 50 pts │ 38 pts │ 76% ← Holiday week
Sprint 16 │ 45 pts │ 44 pts │ 98%
Sprint 15 │ 48 pts │ 45 pts │ 94%
Sprint 14 │ 52 pts │ 40 pts │ 77% ← New team member
Sprint 13 │ 44 pts │ 43 pts │ 98%
Average Velocity: 42 points/sprint
Reliable Range: 40-45 points (90% confidence)
Recommendation for Sprint 19:
Commit to 42 points (stretch goal: 45)
Velocity Factors
Factors Affecting Velocity:
Predictable Reductions:
├── Holidays in sprint: -20% per day
├── Team member PTO: -proportional
├── Major meetings/events: -10%
└── Sprint 1 with new hire: -15%
Unexpected Variations:
├── Production incidents: Variable
├── Scope changes mid-sprint: Variable
├── Technical discoveries: Variable
└── External blockers: Variable
Adjustment Example:
Base velocity: 42 points
Sprint 19 factors:
├── 1 day holiday: -20% of 1/10 = -2%
├── Alice on PTO 2 days: -8% (1 of 4 devs, 2 of 10 days)
└── No other factors
Adjusted capacity: 42 × 0.90 = 38 points
Reference Similar Work
Task Comparison
Estimating: #250 "Add export to CSV feature"
Similar Completed Tasks:
├── #198 "Export to PDF" — 5 points, 12 hrs actual
│ └── Notes: "PDF library had good docs"
├── #167 "Export to Excel" — 8 points, 18 hrs actual
│ └── Notes: "Excel formatting was tricky"
└── #145 "Import from CSV" — 3 points, 6 hrs actual
└── Notes: "Parsing straightforward"
Analysis:
├── CSV export simpler than PDF formatting
├── No special formatting like Excel
├── Similar to CSV import but reverse
Estimate: 3 points
Rationale: "Simpler than import (#145, 3pts) but same domain"
Estimation History by Type
Task Type Historical Analysis:
API Endpoints:
├── Simple CRUD: 2-3 points (avg 2.4)
├── Complex logic: 5-8 points (avg 6.2)
└── External integration: 8-13 points (avg 9.5)
Frontend Components:
├── Simple display: 1-2 points (avg 1.6)
├── Form with validation: 3-5 points (avg 3.8)
└── Complex interactive: 5-8 points (avg 6.1)
Bug Fixes:
├── Known cause: 1-2 points (avg 1.3)
├── Investigation needed: 3-5 points (avg 4.2)
└── Unclear reproduction: 5-8 points (avg 6.8)
Refactoring:
├── Single file: 2-3 points (avg 2.5)
├── Module-level: 5-8 points (avg 6.3)
└── Cross-cutting: 13+ points (avg 15.2)
Breaking Down Large Tasks
Decomposition Pattern
Original Task: "Implement payment system" — 34 points (too large)
Decomposition:
├── Payment provider integration
│ ├── Provider SDK setup — 2 pts
│ ├── API credentials management — 2 pts
│ └── Basic payment flow — 5 pts
│
├── Checkout UI
│ ├── Payment form component — 3 pts
│ ├── Form validation — 2 pts
│ └── Error handling UI — 2 pts
│
├── Backend processing
│ ├── Payment endpoint — 3 pts
│ ├── Webhook handling — 5 pts
│ └── Transaction storage — 3 pts
│
└── Testing & edge cases
├── Unit tests — 3 pts
├── Integration tests — 3 pts
└── Error scenarios — 2 pts
Total after decomposition: 35 points (similar)
But now:
├── Each task is estimable
├── Parallel work possible
├── Progress visible
└── Risks identified early
When to Split Tasks
Split Indicators:
Size-based:
├── > 8 story points → Consider splitting
├── > 13 story points → Must split
└── "It depends" in discussion → Needs clarification
Complexity-based:
├── Multiple systems touched → Split by system
├── Frontend + Backend → Split layers
├── Multiple unknowns → Spike + Implementation
Time-based:
├── > 3 days estimated work → Consider splitting
├── > 1 week → Must split
└── Can't complete in sprint → Definitely split
Examples:
❌ "Build feature X" (vague, large)
✓ "Create X database schema"
✓ "Build X API endpoint"
✓ "Create X frontend form"
✓ "Add X validation logic"
✓ "Write X integration tests"
Estimation Techniques
Planning Poker in GitScrum
Planning Poker Session:
1. Product owner presents task
2. Team asks clarifying questions
3. Each member selects estimate (hidden)
4. All estimates revealed simultaneously
5. High/low discuss reasoning
6. Re-estimate if needed
7. Consensus recorded
Example Session:
Task: "Implement password reset flow"
Round 1:
├── Estimates: 3, 5, 5, 8
├── Discussion: "8 because email templates take time"
├── Response: "We have template system, just new content"
Round 2:
├── Estimates: 5, 5, 5, 5
└── Consensus: 5 points ✓
T-Shirt Sizing for Backlog
Initial Backlog Grooming:
T-Shirt Size → Story Points Range
XS (Extra Small) → 1-2 points
├── Quick wins
├── Config changes
└── Minor fixes
S (Small) → 2-3 points
├── Simple features
├── Standard components
└── Known patterns
M (Medium) → 5 points
├── Typical features
├── Some complexity
└── Clear requirements
L (Large) → 8 points
├── Complex features
├── Multiple parts
└── Some unknowns
XL (Extra Large) → 13+ points
├── Needs splitting
├── Many unknowns
└── Architectural impact
Backlog Sizing Session:
├── #301 Password reset: M → 5 pts
├── #302 Dashboard charts: L → 8 pts
├── #303 Export feature: S → 3 pts
├── #304 Payment system: XL → needs splitting
└── #305 Bug: login error: S → 2 pts
Calibrating Estimates
Actual vs. Estimated Tracking
Sprint 18 Calibration:
Task │ Estimated │ Actual │ Ratio
────────────────────────┼───────────┼────────┼──────
#201 User profile │ 5 pts │ 4 hrs │ 0.8 hr/pt
#202 API refactor │ 8 pts │ 12 hrs │ 1.5 hr/pt
#203 Form validation │ 3 pts │ 3 hrs │ 1.0 hr/pt
#204 Chart component │ 5 pts │ 8 hrs │ 1.6 hr/pt
#205 Bug fix batch │ 3 pts │ 2 hrs │ 0.7 hr/pt
Team average: 1.1 hrs per story point
Insights:
├── Charts took longer (new library learning)
├── API refactor hit unexpected complexity
├── Bug fixes went faster (good debugging)
└── Consider: Inflate chart estimates by 1.5x
Improving Over Time
Estimation Accuracy Trend:
Q1 2024:
├── Sprints completed: 6
├── Avg completion rate: 78%
├── Estimation variance: ±35%
Q2 2024:
├── Sprints completed: 6
├── Avg completion rate: 85%
├── Estimation variance: ±25%
Q3 2024:
├── Sprints completed: 6
├── Avg completion rate: 91%
├── Estimation variance: ±15%
Improvements Made:
├── Started using reference tasks
├── Added spike stories for unknowns
├── Split tasks > 8 points
├── Daily progress updates catch surprises
└── Retrospective focus on estimate misses
Communication Best Practices
Presenting Estimates to Stakeholders
Stakeholder Communication:
❌ Don't say:
"It will take exactly 3 weeks"
"We can definitely finish by Friday"
"That's a 5-point story"
✓ Do say:
"Based on our velocity, we expect 2-3 weeks"
"We're 80% confident in Friday delivery"
"Similar features have taken 1-2 sprints"
Range Estimates:
├── Best case: Everything goes smoothly
├── Expected case: Normal complexity encountered
├── Worst case: Major blockers discovered
Example:
"Password reset feature:
├── Best case: 3 days (no surprises)
├── Expected: 5 days (typical complexity)
└── Worst case: 8 days (email provider issues)
We'll commit to the expected case and update
daily if anything changes."
Handling Estimate Pressure
When Pushed for Lower Estimates:
Scenario: "Can you do it in half the time?"
Response Framework:
1. Acknowledge the need: "I understand the timeline pressure"
2. Explain the estimate basis:
"Our estimate is based on similar past work:
- Feature X took 8 days last month
- This has similar complexity"
3. Offer trade-offs:
"To reduce time, we could:
- Remove Y functionality (saves 2 days)
- Skip automated tests (adds risk)
- Add another developer (some overhead)"
4. Clarify consequences:
"If we force a shorter timeline:
- Quality will suffer
- Technical debt increases
- Future work slows down"
5. Propose alternatives:
"Could we deliver MVP in 5 days,
then iterate with remaining features?"