yebot 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
- Pressure-driven estimates: Fitting estimate to desired timeline
- Best-case thinking: Assuming everything goes perfectly
- Ignoring testing: Development isn't done until it's tested
- Forgetting integration: Time for connecting pieces
- Missing review cycles: Code review, design review, etc.
Do This Instead
- Add buffer: Include time for unknowns and interruptions
- Include all work: Testing, documentation, review, deployment
- Communicate uncertainty: Be honest about confidence level
- Update as you learn: Revise estimates when new info emerges
- 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)