Files
2025-11-30 09:08:06 +08:00

6.4 KiB

description, disable-model-invocation
description disable-model-invocation
Estimate implementation complexity for features and technical tasks false

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)