Agile Estimation Techniques | Story Points & Planning Poker
Estimate work accurately with planning poker, T-shirt sizing, and story points. Build shared understanding, improve sprint planning, and track velocity trends.
6 min read
Estimation is about understanding, not precision. Good estimation creates shared understanding and enables planning. Poor estimation either overpromises or pads excessively. This guide covers practical estimation techniques for agile teams.
Estimation Approaches
| Technique | Best For | Effort |
|---|---|---|
| Planning Poker | Sprint items | Medium |
| T-Shirt Sizing | Roadmap items | Low |
| Affinity Mapping | Many items | Low |
| Time-boxing | Research, spikes | N/A |
Story Points
Relative Estimation
STORY POINTS
════════════
WHAT ARE STORY POINTS:
─────────────────────────────────────
Relative measure of:
├── Complexity
├── Effort
├── Uncertainty
├── Combined into single number
├── Not hours
└── Relative sizing
FIBONACCI SEQUENCE:
─────────────────────────────────────
1, 2, 3, 5, 8, 13, 21
Why Fibonacci:
├── Larger = less precision
├── Forces choice between options
├── Acknowledges uncertainty
├── Gap grows with size
└── Reflects reality
REFERENCE STORIES:
─────────────────────────────────────
Establish baseline:
├── 1 point: "Add field to form"
├── 3 points: "New API endpoint"
├── 5 points: "Feature with tests"
├── 8 points: "Complex integration"
├── 13 points: "Should split"
├── Team calibration
└── Compare new to reference
WHAT POINTS CAPTURE:
─────────────────────────────────────
├── Technical complexity
├── Amount of work
├── Risk/uncertainty
├── Knowledge gaps
├── Dependencies
├── Not just time
└── Holistic view
Planning Poker
Team Estimation
PLANNING POKER
══════════════
HOW IT WORKS:
─────────────────────────────────────
1. Read story aloud
2. Answer clarifying questions
3. Everyone selects card (hidden)
4. Reveal simultaneously
5. Discuss differences
6. Re-vote if needed
7. Consensus or average
EXAMPLE SESSION:
─────────────────────────────────────
Story: "User password reset"
Round 1 (reveal):
├── Alice: 3
├── Bob: 8
├── Carol: 5
├── Dave: 5
└── Wide spread - discuss!
Discussion:
├── Bob: "Need email service integration"
├── Alice: "We have email helper already"
├── Carol: "What about rate limiting?"
├── Team: "Good point, add to story"
└── New understanding
Round 2 (reveal):
├── Alice: 5
├── Bob: 5
├── Carol: 5
├── Dave: 5
└── Consensus: 5 points
WHY IT WORKS:
─────────────────────────────────────
├── Prevents anchoring (simultaneous)
├── Surfaces different perspectives
├── Discussion builds understanding
├── Team owns estimate
├── Wisdom of crowd
└── Collaborative
TIPS:
─────────────────────────────────────
├── Time-box discussions (2-3 min)
├── Defer to implementer
├── If wide spread, discuss more
├── Large items (>13): split
├── Uncertain: default higher
└── Efficient meetings
T-Shirt Sizing
Quick Estimation
T-SHIRT SIZING
══════════════
SIZE DEFINITIONS:
─────────────────────────────────────
XS: Trivial (< 1 day)
S: Small (1-2 days)
M: Medium (3-5 days)
L: Large (1-2 weeks)
XL: Epic (break down first)
WHEN TO USE:
─────────────────────────────────────
├── Roadmap planning
├── Early backlog grooming
├── Quick estimates
├── High-level planning
├── Not sprint-ready
└── Rough sizing
PROCESS:
─────────────────────────────────────
1. List items to estimate
2. Start with obvious ones
3. "Is this S, M, or L?"
4. Quick team consensus
5. Move to next
6. Refine later
CONVERT TO POINTS:
─────────────────────────────────────
When sprint-ready:
├── XS → 1 point
├── S → 2-3 points
├── M → 5-8 points
├── L → 13+ (split first)
├── Rough conversion
└── Detail later
Affinity Mapping
Batch Estimation
AFFINITY ESTIMATION
═══════════════════
FOR MANY ITEMS:
─────────────────────────────────────
When you have many items to estimate:
1. Setup
├── Columns: 1, 2, 3, 5, 8, 13
├── Cards on table
└── Team around table
2. Silent sorting
├── Pick up any card
├── Place in column
├── No talking
├── Can move others' placements
└── 5-10 minutes
3. Discussion
├── Review placements
├── Discuss disagreements
├── Adjust as needed
└── 10 minutes
4. Finalize
├── Record estimates
├── Note large items to split
└── Done
EXAMPLE:
─────────────────────────────────────
│ 1 │ 2 │ 3 │ 5 │ 8 │ 13 │
├───┼───┼───┼────┼────┼─────┤
│ A │ D │ G │ J │ M │ P │
│ B │ E │ H │ K │ N │ │
│ C │ F │ I │ L │ O │ │
30 items estimated in 20 minutes!
WHEN TO USE:
─────────────────────────────────────
├── New project kickoff
├── Many backlog items
├── Quarterly planning
├── Quick calibration
└── Efficient for volume
Improving Estimates
Learning from Experience
IMPROVING ESTIMATION
════════════════════
TRACK ACCURACY:
─────────────────────────────────────
Record for each story:
├── Estimated points
├── Actual effort
├── Surprises encountered
├── What was missed
└── Data for learning
RETROSPECTIVE REVIEW:
─────────────────────────────────────
Discuss:
├── Which estimates were way off?
├── What did we miss?
├── Any patterns?
├── How to estimate better?
└── Continuous improvement
COMMON ESTIMATION ERRORS:
─────────────────────────────────────
Underestimating:
├── Hidden complexity
├── Integration work
├── Testing effort
├── Review/feedback cycles
├── Dependencies
└── Add buffer
Overestimating:
├── Unfamiliar technology (less scary after)
├── Similar past work
├── Existing solutions
└── Adjust calibration
GUIDELINES:
─────────────────────────────────────
├── Break down large items
├── Include testing in estimate
├── Account for reviews
├── Don't estimate > 13 points
├── When uncertain, go higher
├── It's okay to be wrong
└── Learn and improve
GitScrum Estimation
Tool Support
GITSCRUM FOR ESTIMATION
═══════════════════════
EFFORT POINTS:
─────────────────────────────────────
├── Estimate on tasks
├── Sprint planning view
├── Capacity tracking
├── Velocity calculation
└── Built-in support
PLANNING SESSION:
─────────────────────────────────────
├── Backlog refinement view
├── Add estimates
├── Team discussion
├── Record decisions
└── Efficient sessions
VELOCITY TRACKING:
─────────────────────────────────────
├── Points completed per sprint
├── Average velocity
├── Trend over time
├── Planning data
└── Predictability
ESTIMATION HISTORY:
─────────────────────────────────────
├── See past estimates
├── Compare to actual
├── Reference stories
├── Learn from history
└── Improve over time
Best Practices
For Estimation
Anti-Patterns
ESTIMATION MISTAKES:
✗ Manager dictates estimates
✗ Precise hour estimates
✗ No reference stories
✗ Skip discussion
✗ Estimate solo
✗ Never review accuracy
✗ Punish wrong estimates
✗ Estimate huge items