8 min read • Guide 772 of 877
Estimation Techniques for Development Teams
Good estimation helps planning without creating false precision. GitScrum supports various estimation approaches to help teams plan and deliver predictably.
Estimation Approaches
Story Points
STORY POINT ESTIMATION:
┌─────────────────────────────────────────────────────────────┐
│ │
│ WHAT STORY POINTS MEASURE: │
│ │
│ Complexity + Effort + Uncertainty │
│ (Not hours or days) │
│ │
│ WHY RELATIVE: │
│ Humans are better at comparing than predicting │
│ "This is twice as big as that" easier than │
│ "This will take 3.5 days" │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ FIBONACCI SCALE: │
│ 1, 2, 3, 5, 8, 13, 21 │
│ │
│ 1: Trivial change, very well understood │
│ 2: Small, straightforward │
│ 3: Medium, some complexity │
│ 5: Larger, moderate complexity │
│ 8: Complex, some unknowns │
│ 13: Very complex, significant unknowns │
│ 21: Too big - break it down │
│ │
│ WHY FIBONACCI: │
│ Gaps get larger as size increases │
│ Reflects increasing uncertainty with size │
│ Prevents false precision ("is this 6 or 7 points?") │
│ │
│ REFERENCE STORIES: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Team calibration examples: ││
│ │ ││
│ │ 1 pt: Fix typo in UI ││
│ │ 2 pt: Add input validation ││
│ │ 3 pt: New API endpoint (simple CRUD) ││
│ │ 5 pt: Feature with multiple components ││
│ │ 8 pt: Integration with external service ││
│ │ 13 pt: New feature area (consider splitting) ││
│ └─────────────────────────────────────────────────────────┘│
└─────────────────────────────────────────────────────────────┘
T-Shirt Sizing
T-SHIRT SIZE ESTIMATION:
┌─────────────────────────────────────────────────────────────┐
│ │
│ SIZES: │
│ │
│ XS: Hours of work │
│ S: 1-2 days │
│ M: 3-5 days │
│ L: 1-2 weeks │
│ XL: More than 2 weeks (break down) │
│ │
│ USE CASES: │
│ • Quick backlog grooming │
│ • Roadmap planning │
│ • Initial sizing before detailed estimation │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ CONVERTING FOR SPRINT PLANNING: │
│ │
│ High-level: T-shirt sizes │
│ Sprint planning: Story points │
│ │
│ Rough mapping: │
│ XS → 1 point │
│ S → 2-3 points │
│ M → 5 points │
│ L → 8-13 points │
│ XL → Break into smaller stories │
│ │
│ WHY USE BOTH: │
│ T-shirt: Fast, roadmap-level │
│ Points: Detailed, sprint-level │
└─────────────────────────────────────────────────────────────┘
Estimation Sessions
Planning Poker
PLANNING POKER:
┌─────────────────────────────────────────────────────────────┐
│ │
│ PROCESS: │
│ │
│ 1. PO presents story │
│ 2. Team asks questions │
│ 3. Everyone picks card secretly │
│ 4. Reveal simultaneously │
│ 5. Discuss differences │
│ 6. Re-vote if needed │
│ 7. Agree on estimate │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ EXAMPLE SESSION: │
│ │
│ Story: "Add password reset functionality" │
│ │
│ Round 1 votes: │
│ Alex: 5 Sam: 8 Jordan: 5 Taylor: 3 │
│ │
│ Discussion: │
│ Taylor (3): "We have a template for this" │
│ Sam (8): "Email integration is tricky" │
│ Alex (5): "Template helps, but still testing" │
│ │
│ Round 2 votes: │
│ Alex: 5 Sam: 5 Jordan: 5 Taylor: 5 │
│ │
│ Agreed: 5 points │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ TIPS: │
│ • High and low explain first │
│ • 2 rounds max, then average │
│ • Capture assumptions │
│ • Document why if unusual │
└─────────────────────────────────────────────────────────────┘
Affinity Estimation
AFFINITY ESTIMATION (Fast):
┌─────────────────────────────────────────────────────────────┐
│ │
│ USE FOR: Large backlog, quick sizing │
│ │
│ PROCESS: │
│ │
│ 1. Write stories on cards │
│ 2. Silently sort into size buckets │
│ 3. Team reviews together │
│ 4. Discuss and adjust outliers │
│ 5. Assign point values to buckets │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ SETUP: │
│ │
│ SMALLER RELATIVE SIZE LARGER │
│ ────────────────────────────────────────────────────── │
│ │
│ ┌────┐ ┌────┐ ┌────┐ ┌────┐ ┌────┐ ┌────┐ │
│ │ XS │ │ S │ │ M │ │ L │ │ XL │ │XXL │ │
│ │ │ │ │ │ │ │ │ │ │ │SPLIT│ │
│ └────┘ └────┘ └────┘ └────┘ └────┘ └────┘ │
│ │
│ Team members place stories silently │
│ Then discuss disagreements together │
│ │
│ BENEFITS: │
│ • Size 50+ stories in 1 hour │
│ • Whole team participates │
│ • Visual and collaborative │
│ • Good for new backlogs │
└─────────────────────────────────────────────────────────────┘
Improving Estimates
Calibration
ESTIMATE CALIBRATION:
┌─────────────────────────────────────────────────────────────┐
│ │
│ TRACK ACTUALS: │
│ │
│ After each sprint, compare: │
│ │
│ Story Estimated Actual Notes │
│ ───────────── ───────── ────── ───────────────────── │
│ PROJ-101 5 5 Accurate │
│ PROJ-102 3 5 Edge cases missed │
│ PROJ-103 8 6 Overestimated │
│ PROJ-104 2 4 Hidden complexity │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ RETROSPECTIVE QUESTIONS: │
│ │
│ UNDERESTIMATED: │
│ • What did we miss? │
│ • Was scope unclear? │
│ • Hidden dependencies? │
│ • Testing took longer? │
│ │
│ OVERESTIMATED: │
│ • What went smoother than expected? │
│ • Did we pad too much? │
│ • Better tooling/experience? │
│ │
│ ACTIONS: │
│ • Update reference stories │
│ • Add to estimation checklist │
│ • Share learnings with team │
└─────────────────────────────────────────────────────────────┘
Common Mistakes
ESTIMATION PITFALLS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ MISTAKE: Only estimating coding time │
│ FIX: Include testing, review, documentation │
│ │
│ MISTAKE: Optimistic estimates (best case) │
│ FIX: Estimate for normal case with buffer │
│ │
│ MISTAKE: Letting loudest voice win │
│ FIX: Silent voting first (planning poker) │
│ │
│ MISTAKE: Anchoring to first estimate │
│ FIX: Independent estimates before discussion │
│ │
│ MISTAKE: Estimating unknowns with certainty │
│ FIX: Spike first, then estimate │
│ │
│ MISTAKE: Not breaking down large items │
│ FIX: Split anything > 8 points │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ ESTIMATION CHECKLIST: │
│ │
│ ☐ Requirements understood? │
│ ☐ Edge cases identified? │
│ ☐ Dependencies clear? │
│ ☐ Testing approach known? │
│ ☐ Similar work for reference? │
│ ☐ Major unknowns? │
│ ☐ All work types included? │
│ (dev, test, review, docs) │
│ │
│ If many "no" → Story not ready for estimation │
└─────────────────────────────────────────────────────────────┘
When Not to Estimate
No-Estimate Approaches
WHEN TO SKIP ESTIMATES:
┌─────────────────────────────────────────────────────────────┐
│ │
│ CONSIDER NO-ESTIMATES IF: │
│ │
│ • Stories are consistently similar size │
│ • Team is stable and predictable │
│ • Estimation sessions feel like waste │
│ • Focus on throughput, not estimates │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ FLOW-BASED METRICS: │
│ │
│ Instead of: Story points completed │
│ Track: Stories completed per week │
│ │
│ Instead of: Velocity in points │
│ Track: Lead time and cycle time │
│ │
│ Instead of: Sprint commitment │
│ Track: Work in progress limits │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ HYBRID APPROACH: │
│ │
│ T-shirt size for planning/forecasting │
│ No points for individual stories │
│ Count throughput for velocity │
│ │
│ REQUIREMENT: │
│ Stories must be broken down to similar sizes │
│ ("Right-sized" stories) │
│ │
│ IF SIZES VARY WIDELY: │
│ Estimates still provide value │
│ Continue estimating │
└─────────────────────────────────────────────────────────────┘