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

## 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)