7 min read • Guide 282 of 877
Task Estimation Techniques
Estimation is hard because software is inherently uncertain. But better estimation is possible through proven techniques, team collaboration, and learning from past estimates. The goal isn't perfect estimates—it's estimates good enough to plan effectively and predictability that improves over time.
Estimation Approaches
| Technique | Best For | Precision |
|---|---|---|
| Story Points | Sprint planning | Medium |
| T-Shirt Sizes | Rough roadmapping | Low |
| Planning Poker | Team consensus | Medium |
| Time (Hours) | Short, well-known tasks | High (if small) |
Story Points
Relative Estimation
STORY POINTS EXPLAINED
══════════════════════
WHAT THEY MEASURE:
─────────────────────────────────────
├── Complexity (how hard?)
├── Effort (how much work?)
├── Uncertainty (how much unknown?)
└── NOT time (how many hours)
RELATIVE, NOT ABSOLUTE:
─────────────────────────────────────
"This is twice as complex as that"
Not: "This takes 8 hours"
Comparing to known work:
├── Story A = 1 point (our baseline)
├── Story B feels twice as complex = 2 points
├── Story C feels 3x Story A = 3 points
└── Comparison is more accurate than guessing time
FIBONACCI SCALE:
─────────────────────────────────────
1, 2, 3, 5, 8, 13, 21...
Why gaps grow:
├── Larger items have more uncertainty
├── Precision decreases with size
├── 13 vs 14 is false precision
├── 8 vs 13 is meaningful difference
└── Forces "about this size" thinking
TYPICAL MEANINGS:
─────────────────────────────────────
1 point: Trivial, well understood
2 points: Small, straightforward
3 points: Medium, some complexity
5 points: Large, multiple parts
8 points: Very large, significant work
13 points: Should probably split
21+ points: Definitely split
Using Story Points
STORY POINT ESTIMATION
══════════════════════
STEP 1: ESTABLISH REFERENCE STORIES
─────────────────────────────────────
Find completed stories team agrees on:
├── 1-point reference: "Add logging to endpoint"
├── 3-point reference: "User profile page"
├── 5-point reference: "Payment integration"
└── Use these as comparison points
STEP 2: COMPARE NEW STORIES
─────────────────────────────────────
"How does this compare to our 3-point reference?"
├── About the same? 3 points.
├── Bit more complex? 5 points.
├── Less complex? 2 points.
└── Comparison is key
STEP 3: WHOLE TEAM ESTIMATES
─────────────────────────────────────
Everyone estimates together.
Different perspectives reveal:
├── "Wait, this is more complex than you think"
├── "I've done this before, it's simpler"
├── "What about [edge case]?"
└── Discussion improves accuracy
STEP 4: TRACK AND LEARN
─────────────────────────────────────
After sprint:
├── Did 5-point stories take ~5x as long as 1-point?
├── Which estimates were way off?
├── Why were they wrong?
├── Adjust future estimates based on learning
└── Calibration improves over time
Planning Poker
Team Estimation
PLANNING POKER PROCESS
══════════════════════
SETUP:
─────────────────────────────────────
├── Each team member has cards: 1, 2, 3, 5, 8, 13, ?
├── Product Owner has stories to estimate
├── Facilitator (Scrum Master) runs process
└── Whole team participates
PROCESS:
─────────────────────────────────────
1. PO READS STORY
"As a user, I want to save my cart..."
Answers clarifying questions.
(2 minutes)
2. TEAM CONSIDERS
Everyone thinks about complexity.
No discussion yet.
(30 seconds)
3. SIMULTANEOUS REVEAL
"3, 2, 1, show cards!"
Everyone reveals at once.
Prevents anchoring.
4. IF CONSENSUS:
All cards same or adjacent (5, 5, 5, 3)
→ Take the majority, move on.
5. IF DIVERGENCE:
Cards spread (2, 5, 13)
→ Discuss differences.
High: "I think this needs [complex thing]"
Low: "We have code for this, it's simpler"
→ Re-estimate after discussion.
6. RECORD AND MOVE ON
Story gets the estimate.
Move to next story.
Timebox total session.
BENEFITS:
─────────────────────────────────────
├── Whole team input
├── Surface assumptions
├── Prevent dominance
├── Build shared understanding
├── More accurate than solo estimates
└── Team ownership of estimates
T-Shirt Sizing
Rough Estimation
T-SHIRT SIZING
══════════════
WHEN TO USE:
─────────────────────────────────────
├── Roadmap planning (rough)
├── Initial backlog sizing
├── Quick triage
├── When precision isn't needed
└── Faster than story points
THE SIZES:
─────────────────────────────────────
XS: Trivial, < 1 day
S: Small, 1-2 days
M: Medium, 2-5 days
L: Large, 1-2 weeks
XL: Epic, > 2 weeks (split it)
USAGE:
─────────────────────────────────────
In roadmap planning:
"Q3 features:
├── User authentication: M
├── Payment integration: L
├── Dashboard: L
├── Reporting: XL → split
└── Rough capacity: Can we fit this?"
CONVERT TO POINTS LATER:
─────────────────────────────────────
When sprint planning:
├── Take L item
├── Break down into stories
├── Estimate each in points
├── More precision when needed
└── T-shirts for planning, points for sprints
Improving Estimates
Learning from Variance
ESTIMATION IMPROVEMENT
══════════════════════
TRACK ACTUAL VS ESTIMATED:
─────────────────────────────────────
After each sprint, compare:
Story Estimated Actual Variance
───────────────────────────────────────────
Login flow 5 pts 8 pts +60%
Profile page 3 pts 3 pts 0%
Search 8 pts 5 pts -38%
Payment 13 pts 13 pts 0%
───────────────────────────────────────────
ANALYZE WHY:
─────────────────────────────────────
Login (+60%):
"OAuth complexity was higher than expected.
We didn't account for error handling."
→ Next time: Factor in auth complexity more
Search (-38%):
"Library did most of the work.
We overestimated custom work."
→ Next time: Check if libraries exist first
RETROSPECTIVE DISCUSSION:
─────────────────────────────────────
"Which estimates were off? Why?"
├── Uncover patterns
├── Adjust calibration
├── Update reference stories
├── Improve process
└── Get better over time
COMMON REASONS FOR VARIANCE:
─────────────────────────────────────
Underestimate:
├── Forgot testing time
├── Edge cases discovered
├── Integration harder than expected
├── Technical debt slowed work
├── Dependencies blocked
Overestimate:
├── Had reusable code
├── Simpler than expected
├── Found better solution
├── Less testing needed
└── Learn from both!
Breaking Down Large Items
SPLITTING FOR ACCURACY
══════════════════════
LARGE ITEMS ARE INACCURATE:
─────────────────────────────────────
├── More unknown unknowns
├── Harder to compare
├── Compound uncertainty
├── Estimates often wrong
└── Split into smaller pieces
SPLITTING TECHNIQUE:
─────────────────────────────────────
Story: "User can make payment" (13 pts)
Split into:
├── Show payment form (2 pts)
├── Validate card input (2 pts)
├── Process with Stripe (5 pts)
├── Confirmation screen (2 pts)
├── Error handling (3 pts)
└── Total: 14 pts (but more accurate)
Each piece:
├── More comparable to references
├── Less uncertainty
├── Better estimate
└── Reveals hidden complexity
RULE:
─────────────────────────────────────
Anything > 8 points: Question it
Anything > 13 points: Split it
Prefer 1-5 point stories
GitScrum Estimation
Estimation Features
GITSCRUM ESTIMATION TOOLS
═════════════════════════
STORY POINTS:
─────────────────────────────────────
Task → Estimate field
├── Enter points
├── Visible on board
├── Sums for sprint capacity
├── Velocity tracking
└── Historical data
PLANNING POKER:
─────────────────────────────────────
Sprint Planning → Estimation Mode
├── Team members estimate simultaneously
├── Reveal together
├── Discuss differences
├── Lock in estimate
└── Built-in workflow
VELOCITY:
─────────────────────────────────────
Reports → Velocity
├── Points per sprint
├── Running average
├── Trend over time
├── Use for capacity planning
└── Compare committed vs completed
ESTIMATION REPORT:
─────────────────────────────────────
├── Stories by estimate
├── Completion by estimate
├── Accuracy trends
├── Identify patterns
└── Improve over time
Best Practices
For Estimation
- Relative, not absolute — Compare to known work
- Whole team estimates — Multiple perspectives
- Break down large items — Smaller is more accurate
- Use reference stories — Calibration points
- Track and learn — Improve from variance
Anti-Patterns
ESTIMATION MISTAKES:
✗ One person estimates
✗ Hours for everything
✗ Never reviewing accuracy
✗ Estimating in isolation
✗ Giant stories (13+ pts)
✗ False precision (6.5 points)
✗ Punishing wrong estimates
✗ Using estimates as commitments