Estimation for Magento 2 Projects

What Are Story Points?

Story points estimate relative effort, not absolute time.

Fibonacci Scale

1  - Trivial, few hours
2  - Small, half day
3  - Medium, 1 day
5  - Large, 2-3 days
8  - Extra large, 1 week
13 - Very large, 2 weeks
21 - Huge, needs splitting

Why Story Points?

Pros:
- Relative sizing avoids false precision
- Accounts for complexity, uncertainty, effort
- Velocity tracks team capacity
- Better for long-term planning

Cons:
- Takes time to calibrate
- Different teams have different scales
- Not directly convertible to hours

Planning Poker

1. Discuss the task
2. Each member selects a card
3. Reveal simultaneously
4. Discuss differences
5. Re-estimate if needed
6. Take average of estimates

Example:
Team estimates "Add wishlist feature":
Developer A: 5
Developer B: 8
Developer C: 5
Developer D: 8
Average: 6.5 → Round to 8

Story Point Breakdown

// Factors affecting story points
$factors = [
    'complexity' => 3,    // Technical complexity
    'effort' => 2,        // Lines of code, tests
    'uncertainty' => 2,   // Unknown requirements
    'dependencies' => 1,  // External dependencies
];

// Total = sum of factors (capped at 13)
$total = min(array_sum($factors), 13);

Velocity

Calculating Velocity

Sprint 1: 21 points completed
Sprint 2: 24 points completed
Sprint 3: 19 points completed
Sprint 4: 22 points completed

Average Velocity: (21 + 24 + 19 + 22) / 4 = 21.5 points/sprint

Use velocity for:
- Sprint planning
- Release forecasting
- Capacity planning

Velocity Trends

Stable velocity: Team is predictable
Increasing velocity: Team is improving
Decrealing velocity: Investigate issues

Velocity should stabilize after 3-4 sprints.

Estimation Techniques

Three-Point Estimation

Estimate = (Optimistic + 4 × Most Likely + Pessimistic) / 6

Example for checkout feature:
- Optimistic: 3 days
- Most Likely: 5 days
- Pessimistic: 10 days

Estimate = (3 + 4×5 + 10) / 6 = 33/6 = 5.5 days

Standard Deviation = (Pessimistic - Optimistic) / 6
= (10 - 3) / 6 = 1.17 days

Range: 5.5 ± 1.17 days (4.33 to 6.67 days)

Task Breakdown

// Break down large tasks
$checkoutFeature = [
    'task_1' => [
        'name' => 'Cart API endpoints',
        'estimate' => 3, // hours
        'risk' => 'low'
    ],
    'task_2' => [
        'name' => 'Payment integration',
        'estimate' => 8,
        'risk' => 'high'
    ],
    'task_3' => [
        'name' => 'Order creation logic',
        'estimate' => 5,
        'risk' => 'medium'
    ],
    'task_4' => [
        'name' => 'Unit tests',
        'estimate' => 4,
        'risk' => 'low'
    ],
    'task_5' => [
        'name' => 'Integration tests',
        'estimate' => 3,
        'risk' => 'medium'
    ],
    'total' => 23, // hours
];

T-Shirt Sizing

XS: 1-2 hours
S:  0.5 days
M:  1 day
L:  2-3 days
XL: 1 week
XXL: 2+ weeks (needs splitting)

Use for:
- Quick high-level estimates
- Portfolio planning
- Initial backlog grooming

Reference-Based Estimation

"This feature is similar to the wishlist feature we did last month."

Similar = same size
Bigger = add 1-2 points
Smaller = subtract 1-2 points

Benefits:
- Uses actual experience
- More accurate over time
- Team learns together

Cone of Uncertainty

Project Start:    Accuracy ±4x
After Planning:   Accuracy ±2x
After Design:     Accuracy ±1.5x
After Prototype:  Accuracy ±1.2x
During Dev:       Accuracy ±1.1x

Meaning:
- Early estimates are very uncertain
- Get more accurate as you learn
- Never give precise early estimates

Estimation Buffers

Buffer Types:
1. Task buffer: 15-20% per task
2. Project buffer: 25% of total
3. Management buffer: 10-15%

Example:
Base estimate: 100 hours
Task buffer (20%): 20 hours
Project buffer (25%): 25 hours
Total: 145 hours

Risk-Adjusted Estimates

// Add risk to estimates
$riskFactors = [
    'new_technology' => 1.3,    // 30% buffer
    'external_api' => 1.2,      // 20% buffer
    'unclear_requirements' => 1.4, // 40% buffer
    'integration_testing' => 1.25, // 25% buffer
];

$baseEstimate = 40; // hours
$riskMultiplier = 1.3; // new technology risk

$adjustedEstimate = $baseEstimate * $riskMultiplier;
// 40 × 1.3 = 52 hours

Confidence Levels

50% confidence: Most likely scenario
80% confidence: Add 20-30% buffer
95% confidence: Add 50-60% buffer

Example:
- 50% confidence: 10 days
- 80% confidence: 13 days
- 95% confidence: 16 days

Communicate: "I'm 80% confident this will take 13 days."

When Estimates Are Wrong

Handling Underestimation

1. Acknowledge early
2. Explain why (new complexity discovered)
3. Provide updated estimate
4. Discuss scope reduction options
5. Don't blame, learn

Scope Management

If estimate exceeds time:
1. Identify MVP features
2. Defer nice-to-haves
3. Negotiate deadline
4. Add resources (last resort)

Example:
Original: 20 days for full feature
Revised: 12 days for MVP, 8 more for enhancements

Estimation Tracking

Compare Estimates vs Actual

$projectData = [
    'feature' => 'Wishlist',
    'estimated_days' => 5,
    'actual_days' => 7,
    'variance' => 40%,
    'reasons' => [
        'Underestimated testing',
        'Dependency delay'
    ]
];

// Track variance over time
$teamMetrics = [
    'average_variance' => 25%,
    'trend' => 'improving',
    'common_issues' => [
        'Testing underestimated',
        'Integration complexity'
    ]
];

Estimation Retrospectives

Monthly review:
1. What did we estimate vs actual?
2. What caused variance?
3. What can we improve?
4. Update estimation guidelines

Common findings:
- We consistently underestimate testing by 30%
- New features take 2x longer than similar old ones
- External dependencies add 1 week

Estimation Guidelines

// Document team-specific guidelines
$estimationGuide = [
    'testing' => 'Add 30% to development estimate',
    'integration' => 'Add 20% for external APIs',
    'review' => 'Add 2 days for code review',
    'deployment' => 'Add 1 day for deployment',
    'buffer' => 'Add 15% for unknowns',
];

// New feature estimate calculation
function estimateFeature($baseHours) {
    $guide = getEstimationGuide();
    
    return $baseHours 
        * 1.3  // testing
        * 1.2  // integration
        + 16   // review (2 days)
        + 8    // deployment (1 day)
        * 1.15; // buffer
}

Historical Data

Maintain estimation database:

Feature | Estimate | Actual | Variance | Notes
--------|----------|--------|----------|------
Wishlist| 5 days   | 7 days | +40%     | Testing
Search  | 8 days   | 8 days | 0%       | On target
Checkout| 10 days  | 14 days| +40%     | Payment API

Use data to:
- Calibrate future estimates
- Identify estimation blind spots
- Set team expectations
- Improve accuracy over time

Common Estimation Pitfalls

1. Anchoring: First estimate sticks
2. Optimism bias: Things always take longer
3. Planning fallacy: Ignore past data
4. Parkinson's Law: Work expands to fill time
5. Brooks's Law: Adding people delays projects

Counter-strategies:
- Use reference-based estimation
- Track actual vs estimate
- Include buffer for uncertainty
- Break down large tasks
- Consider team velocity