Estimation Techniques | Story Points & More
Use story points, relative estimation, and reference stories for accurate planning. GitScrum supports various estimation approaches for team predictability.
8 min read
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 │
└─────────────────────────────────────────────────────────────┘