Task Estimation Techniques | Accurate Planning

Estimate accurately with story points, planning poker, and T-shirt sizing. GitScrum tracks velocity, estimate variance, and calibrates team accuracy over time.

7 min read

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