estimate-complexity

What this skill does

# Estimate Complexity

Provide structured complexity estimates for features and tasks to help with planning and prioritization.

## When to Use

- During sprint planning
- When scoping new features
- Before committing to timelines
- When breaking down large initiatives

## Used By

- Full-Stack Engineer
- Frontend Engineer
- Backend Engineer
- DevOps Engineer

---

## Complexity Estimation Framework

### T-Shirt Sizes

| Size | Description | Typical Scope |
|------|-------------|---------------|
| **XS** | Trivial change | Config change, copy update, minor fix |
| **S** | Small, well-understood | Single component, simple API endpoint |
| **M** | Moderate complexity | Multiple components, some unknowns |
| **L** | Significant effort | Cross-cutting changes, new patterns |
| **XL** | Major initiative | New system, architectural changes |

---

## Estimation Template

```markdown
## Complexity Estimate: [Feature/Task Name]

### Summary
**T-Shirt Size**: [XS / S / M / L / XL]
**Confidence**: [High / Medium / Low]

### Breakdown

| Component | Effort | Notes |
|-----------|--------|-------|
| [Component 1] | [XS-XL] | [Details] |
| [Component 2] | [XS-XL] | [Details] |
| [Component 3] | [XS-XL] | [Details] |

### Key Complexity Drivers

1. **[Driver 1]**: [Why this adds complexity]
2. **[Driver 2]**: [Why this adds complexity]
3. **[Driver 3]**: [Why this adds complexity]

### Risk Factors

| Risk | Impact | Mitigation |
|------|--------|------------|
| [Risk 1] | [H/M/L] | [Strategy] |
| [Risk 2] | [H/M/L] | [Strategy] |

### Unknowns

- [ ] [Unknown 1] - Could affect estimate by [amount]
- [ ] [Unknown 2] - Need to spike/investigate

### Suggested Breakdown

If size is L or XL, break into smaller deliverables:

1. **Phase 1**: [Scope] - Size: [S/M]
2. **Phase 2**: [Scope] - Size: [S/M]
3. **Phase 3**: [Scope] - Size: [S/M]

### Dependencies

- Blocked by: [Dependency]
- Blocks: [Other work]

### Recommendations

[Any suggestions for approach, sequencing, or risk reduction]
```

---

## Complexity Indicators

### Factors That Increase Complexity

**Technical**
- New technology or pattern not used before
- Integration with external systems
- Performance-critical requirements
- Complex state management
- Database migrations on large tables
- Security-sensitive functionality

**Organizational**
- Cross-team coordination required
- Unclear or changing requirements
- Multiple stakeholder approval needed
- Compliance or legal review required

**Code Quality**
- Working in unfamiliar codebase area
- Technical debt in affected areas
- Missing test coverage
- Poor documentation

### Factors That Decrease Complexity

- Similar work done before (pattern exists)
- Well-defined requirements
- Strong test coverage
- Clear ownership and decision-making
- Good documentation
- Modern, maintained dependencies

---

## Confidence Levels

### High Confidence
- Similar work completed before
- All requirements are clear
- Technology is well-understood
- No significant unknowns

### Medium Confidence
- Some new elements but core is understood
- Requirements are mostly clear
- Some unknowns that are bounded

### Low Confidence
- New technology or pattern
- Requirements are still evolving
- Significant unknowns exist
- External dependencies unclear

**When confidence is low**: Consider a spike/investigation before committing to estimate.

---

## Breaking Down Large Tasks

If the estimate is L or XL, it should be broken down. Use these strategies:

### 1. Vertical Slicing
Break by user-facing functionality:
- Slice 1: Minimal viable flow
- Slice 2: Add edge cases
- Slice 3: Polish and optimization

### 2. Horizontal Slicing
Break by technical layer:
- Phase 1: Data model and API
- Phase 2: Frontend implementation
- Phase 3: Integration and testing

### 3. Risk-First Slicing
Address unknowns first:
- Phase 1: Spike on risky parts
- Phase 2: Core implementation
- Phase 3: Polish and edge cases

---

## Estimation Anti-Patterns

### Don't Do This

1. **Pressure-driven estimates**: Fitting estimate to desired timeline
2. **Best-case thinking**: Assuming everything goes perfectly
3. **Ignoring testing**: Development isn't done until it's tested
4. **Forgetting integration**: Time for connecting pieces
5. **Missing review cycles**: Code review, design review, etc.

### Do This Instead

1. **Add buffer**: Include time for unknowns and interruptions
2. **Include all work**: Testing, documentation, review, deployment
3. **Communicate uncertainty**: Be honest about confidence level
4. **Update as you learn**: Revise estimates when new info emerges
5. **Track actuals**: Compare estimates to actual to improve

---

## Quick Estimation Checklist

Before providing an estimate, consider:

### Scope
- [ ] Are requirements clear and complete?
- [ ] Is scope explicitly bounded?
- [ ] Are acceptance criteria defined?

### Technical
- [ ] Have you worked in this area before?
- [ ] Are there existing patterns to follow?
- [ ] Are dependencies understood?
- [ ] Is the data model clear?

### Testing
- [ ] What testing is required?
- [ ] Is there existing test coverage?
- [ ] Are there test data needs?

### Deployment
- [ ] Any database migrations?
- [ ] Feature flag needed?
- [ ] Configuration changes?
- [ ] Documentation updates?

### Coordination
- [ ] Other teams involved?
- [ ] Review cycles needed?
- [ ] Stakeholder approval required?

---

## Example Estimates

### XS Example: Copy Update
```
Task: Update error message text
Size: XS
Confidence: High
Breakdown:
- Edit: 10 min
- Test: 10 min
- Deploy: Automatic
```

### S Example: New API Endpoint
```
Task: Add endpoint to fetch user preferences
Size: S
Confidence: High
Breakdown:
- API implementation: 2 hours
- Tests: 1 hour
- Documentation: 30 min
```

### M Example: New Feature Component
```
Task: Add notification preferences UI
Size: M
Confidence: Medium
Breakdown:
- Component design: 2 hours
- State management: 2 hours
- API integration: 2 hours
- Testing: 3 hours
- Accessibility: 2 hours
```

### L Example: New Subsystem
```
Task: Implement real-time notifications
Size: L
Confidence: Medium
Key Drivers:
- WebSocket infrastructure needed
- Multiple notification types
- Delivery guarantees
- UI notifications component

Suggested Breakdown:
1. WebSocket infrastructure (M)
2. Backend notification service (M)
3. Frontend notification component (S)
4. Integration and testing (S)
```