Story Points vs Effort Points: Estimation Guide

Story points and effort points both measure work complexity, but they approach estimation differently. GitScrum uses effort points with a simplified scale (XS to XL) that includes hour guidelines, making estimation more accessible for teams while maintaining the relative sizing benefits of story points.

Comparison Overview

Understanding Story Points

TRADITIONAL STORY POINTS
════════════════════════

CONCEPT:
─────────────────────────────────────
Story points measure RELATIVE complexity
Not hours, not days - pure comparison

"How complex is Task B compared to Task A?"
If Task A = 3 points and Task B is twice as complex
Then Task B = 5 or 8 points

FIBONACCI SCALE:
─────────────────────────────────────
1  - Trivial (reference baseline)
2  - Simple
3  - Small
5  - Medium
8  - Large
13 - Very large
21 - Epic (should be broken down)

WHY FIBONACCI?
─────────────────────────────────────
├── Uncertainty grows with size
├── Harder to distinguish 14 vs 15
├── Gaps force meaningful choices
└── Reflects natural estimation limits

EXAMPLE:
─────────────────────────────────────
Reference task: "Add validation to form" = 3 pts

Comparing new tasks:
├── "Change button color" → smaller → 1 pt
├── "Add date picker" → similar → 3 pts
├── "Build user dashboard" → much larger → 13 pts
└── "Implement auth system" → epic → 21 pts (split!)

Understanding Effort Points

GITSCRUM EFFORT POINTS
══════════════════════

CONCEPT:
─────────────────────────────────────
Effort points combine relative sizing
with optional hour guidelines

Same relative comparison benefits
Plus practical time references

T-SHIRT SCALE WITH HOURS:
─────────────────────────────────────
┌────────┬─────────┬─────────────────────┐
│ Size   │ Points  │ Typical Duration    │
├────────┼─────────┼─────────────────────┤
│ XS     │ 1       │ Under 2 hours       │
│ S      │ 2       │ 2-4 hours           │
│ M      │ 3       │ 4-8 hours (1 day)   │
│ L      │ 5       │ 1-2 days            │
│ XL     │ 8       │ 2-5 days            │
└────────┴─────────┴─────────────────────┘

WHY THIS WORKS:
─────────────────────────────────────
├── Simple to understand
├── Only 5 options to choose from
├── Hour guides reduce debates
├── Still enables velocity tracking
└── Works for new and experienced teams

EXAMPLE:
─────────────────────────────────────
Task: "Add user profile editing"

Breaking it down:
├── Quick fix? Under 2 hrs? → XS (1 pt)
├── Half day work? → S (2 pts)
├── Full day effort? → M (3 pts)
├── Couple of days? → L (5 pts)
└── Week of work? → XL (8 pts)

Team consensus: "About 2 days" → L (5 pts)

When to Use Each

CHOOSING YOUR APPROACH
══════════════════════

USE EFFORT POINTS WHEN:
─────────────────────────────────────
✓ Team is new to agile estimation
✓ Stakeholders ask "how long?"
✓ Need concrete planning references
✓ Mixed experience levels on team
✓ Simpler is better for your context
✓ Converting from hour-based estimates

USE STORY POINTS WHEN:
─────────────────────────────────────
✓ Team has mature estimation practice
✓ Abstract complexity works well
✓ Fibonacci granularity needed
✓ Team resists time associations
✓ Large variance in individual speeds
✓ Already have established velocity

HYBRID APPROACH:
─────────────────────────────────────
GitScrum effort points support both:
├── Use T-shirt sizes (visual)
├── Track point values (numeric)
├── Reference hours (optional)
└── Calculate velocity (same as story points)

Estimation Techniques

HOW TO ESTIMATE
═══════════════

PLANNING POKER:
─────────────────────────────────────
1. Present the task/story
2. Discuss requirements
3. Everyone picks size simultaneously
4. Reveal choices
5. Discuss outliers
6. Re-vote if needed
7. Consensus or average

Example session:
┌─────────────────────────────────────┐
│ Task: "Implement password reset"    │
├─────────────────────────────────────┤
│ Vote 1:                             │
│ Dev A: M    Dev B: L    Dev C: M    │
│                                     │
│ Discussion: "What about email?"     │
│ Dev B: "Forgot about template"      │
│                                     │
│ Vote 2:                             │
│ Dev A: M    Dev B: M    Dev C: M    │
│                                     │
│ Consensus: M (3 points)             │
└─────────────────────────────────────┘

T-SHIRT SIZING:
─────────────────────────────────────
Quick relative sizing method:

1. Sort tasks by complexity
2. Assign T-shirt sizes
3. Convert to points

┌────────────────────────────────────────┐
│ XS │ S │ M │ L │ XL │                  │
├────┼───┼───┼───┼────┤                  │
│ T1 │T2 │T4 │T6 │ T8 │ ← Tasks sorted   │
│    │T3 │T5 │T7 │    │                  │
│    │   │   │   │    │                  │
└────┴───┴───┴───┴────┘

REFERENCE COMPARISON:
─────────────────────────────────────
1. Establish reference tasks per size
2. Compare new tasks to references
3. Match to closest reference

Reference library:
├── XS: "Update config value"
├── S:  "Add form validation"
├── M:  "Create new API endpoint"
├── L:  "Build dashboard widget"
└── XL: "Implement integration"

Sprint Planning with Points

CAPACITY PLANNING
═════════════════

CALCULATING CAPACITY:
─────────────────────────────────────
Team: 4 developers
Sprint: 2 weeks (10 working days)
Historical velocity: 35-40 pts/sprint

Available capacity:
├── Account for PTO, meetings
├── Include buffer for unknowns
└── Don't overcommit

Example:
┌─────────────────────────────────────┐
│ SPRINT CAPACITY                     │
├─────────────────────────────────────┤
│ Historical velocity: 38 pts avg     │
│ This sprint:                        │
│ ├── Dev A: Full (10 days)           │
│ ├── Dev B: Full (10 days)           │
│ ├── Dev C: 8 days (2 PTO)           │
│ └── Dev D: Full (10 days)           │
│                                     │
│ Adjusted capacity: 38 × 0.9 = 34 pts│
│ Buffer (10%): 3 pts                 │
│ Safe commitment: 31 pts             │
└─────────────────────────────────────┘

SPRINT BACKLOG:
─────────────────────────────────────
┌─────────────────────────────────────┐
│ Story/Task            │ Effort     │
├───────────────────────┼────────────┤
│ User profile editing  │ L (5 pts)  │
│ Password reset flow   │ M (3 pts)  │
│ Dashboard widgets     │ L (5 pts)  │
│ API rate limiting     │ M (3 pts)  │
│ Bug: Login timeout    │ S (2 pts)  │
│ Email notifications   │ L (5 pts)  │
│ Settings page         │ M (3 pts)  │
│ Documentation update  │ S (2 pts)  │
├───────────────────────┼────────────┤
│ TOTAL COMMITTED       │ 28 pts     │
│ Buffer remaining      │ 3 pts      │
└───────────────────────┴────────────┘

Velocity Tracking

MEASURING VELOCITY
══════════════════

WHAT IS VELOCITY?
─────────────────────────────────────
Points completed per sprint
Average over time = predictable capacity

Sprint    │ Committed │ Completed
──────────┼───────────┼──────────
Sprint 1  │ 35 pts    │ 32 pts
Sprint 2  │ 35 pts    │ 36 pts
Sprint 3  │ 38 pts    │ 35 pts
Sprint 4  │ 35 pts    │ 38 pts
Sprint 5  │ 38 pts    │ 37 pts
──────────┼───────────┼──────────
Average   │           │ 35.6 pts

VELOCITY CHART:
─────────────────────────────────────
Points │
   40  │      ■         ■
       │  ■       ■         ■
   35  │──────────────────────  Average
       │
   30  │  ■
       │
   25  ├──────────────────────────
       S1  S2  S3  S4  S5  S6

USING VELOCITY:
─────────────────────────────────────
├── Plan future sprints
├── Project completion dates
├── Identify capacity changes
├── Detect estimation drift
└── Communicate with stakeholders

Example projection:
Remaining work: 180 points
Velocity: 36 pts/sprint
Estimated sprints: 5 (10 weeks)

Common Mistakes

ESTIMATION ANTI-PATTERNS
════════════════════════

MISTAKE 1: CONVERTING TO HOURS
─────────────────────────────────────
❌ "1 point = 4 hours"
❌ "How many hours is an L?"
❌ Treating points as time units

✓ Points measure complexity, not time
✓ Hour guides are references, not rules
✓ Velocity normalizes over time

MISTAKE 2: INDIVIDUAL ESTIMATES
─────────────────────────────────────
❌ "This is 5 points for me"
❌ Adjusting for individual speed
❌ Different scales per person

✓ Team estimates (consensus)
✓ Single scale for all
✓ Velocity accounts for team mix

MISTAKE 3: NEVER RECALIBRATING
─────────────────────────────────────
❌ Same references forever
❌ Ignoring estimation drift
❌ Not reviewing actuals

✓ Revisit reference tasks quarterly
✓ Compare estimates to actuals
✓ Adjust as team changes

MISTAKE 4: OVER-PRECISION
─────────────────────────────────────
❌ "This is exactly 4.5 points"
❌ Debating XS vs S for 20 minutes
❌ Analysis paralysis

✓ Accept estimation uncertainty
✓ Round to nearest size
✓ Timebox discussions (2 min/item)

Best Practices

1. Estimate as a team - consensus builds shared understanding
2. Use reference tasks - compare, don't calculate
3. Track velocity - patterns emerge over 5+ sprints
4. Include everything - testing, review, documentation
5. Split large items - nothing over XL/8 points
6. Timebox estimation - 2 minutes per item max
7. Review regularly - retro on estimation accuracy
8. Trust the process - velocity normalizes variance

GitScrum Setup

CONFIGURING EFFORT POINTS
═════════════════════════

TASK ESTIMATION:
─────────────────────────────────────
When creating/editing a task:
1. Open task details
2. Find Effort field
3. Select size: XS, S, M, L, XL
4. Points auto-calculated

SPRINT PLANNING VIEW:
─────────────────────────────────────
Sprint backlog shows:
├── Total committed points
├── Capacity threshold
├── Individual task efforts
└── Progress tracking

VELOCITY REPORTS:
─────────────────────────────────────
Workspace → Reports → Sprint KPIs
├── Points per sprint
├── Completion rates
├── Burndown progression
└── Trend analysis

Related Solutions

• Sprint Planning and Execution
• Agile Estimation Techniques
• Velocity Tracking Guide
• Technical Debt with Effort Points