# TASK_SIZING_RULES.md - Hybrid Protocol Task Sizing Guidelines

## Purpose
Consistent task sizing enables better planning, resource allocation, and predictability. This document defines the sizing framework for all tasks in the Hybrid Protocol system.

## Sizing Scale

### XS (Extra Small) - < 1 hour
**Characteristics:**
- Trivial changes
- Documentation updates
- Configuration tweaks
- Simple bug fixes
- Minor text edits

**Examples:**
- Fix typo in documentation
- Update configuration value
- Add missing tag to task
- Format code in single file
- Update timestamp

**Validation:**
- Can be completed in one sitting
- No dependencies on other work
- Minimal testing required
- Zero risk of regression

### S (Small) - 1-4 hours
**Characteristics:**
- Simple features
- Basic bug fixes
- Small refactors
- Single-file changes
- Straightforward tasks

**Examples:**
- Add new API endpoint (simple)
- Fix medium-complexity bug
- Implement simple UI component
- Add basic validation
- Update small section of documentation

**Validation:**
- Clear acceptance criteria
- Limited scope
- Can be tested independently
- Low risk

### M (Medium) - 4-8 hours
**Characteristics:**
- Moderate complexity
- Multiple components
- Some integration work
- Requires planning
- May need collaboration

**Examples:**
- Implement feature with backend/frontend changes
- Refactor medium-sized module
- Add comprehensive test suite
- Integrate with external service
- Performance optimization

**Validation:**
- Requires design/planning
- Multiple acceptance criteria
- Integration testing needed
- Medium risk

### L (Large) - 8-16 hours
**Characteristics:**
- High complexity
- Cross-cutting changes
- Significant design work
- Multiple dependencies
- Requires thorough testing

**Examples:**
- Major feature implementation
- Architecture changes
- Database schema migration
- Security feature implementation
- Complex integration

**Validation:**
- Requires detailed design doc
- Multiple stakeholders
- Extensive testing required
- High risk

### XL (Extra Large) - 16+ hours
**Characteristics:**
- Epic-level work
- Multiple phases
- Strategic impact
- High uncertainty
- Should be broken down

**Examples:**
- New system implementation
- Major platform upgrade
- Complete rewrite of module
- New product feature set

**Validation:**
- MUST be broken into smaller tasks
- Requires project plan
- Multiple review checkpoints
- Very high risk

## Sizing Process

### Step 1: Initial Estimate
When creating task in INBOX.md:
1. Consider complexity, not just time
2. Use historical data if available
3. Apply sizing rules above
4. Mark as estimate (e.g., "Size: M (estimate)")

### Step 2: Refinement
Before starting work:
1. Break down XL tasks into L or smaller
2. Clarify ambiguous requirements
3. Identify dependencies
4. Update size if needed

### Step 3: Actual Size
When completing task in OUTBOX.md:
1. Record actual time/complexity
2. Update size field (e.g., "Size: M (actual: 6 hours)")
3. Note any discrepancies from estimate

## Sizing Guidelines

### When in doubt, size up
- Better to overestimate than underestimate
- Padding for unknown unknowns
- Account for review/testing time

### Break down when:
- Task spans multiple domains
- Uncertainty > 30%
- Dependencies unclear
- Risk level high

### Consider these factors:
1. **Complexity:** How hard is it?
2. **Uncertainty:** How much is unknown?
3. **Dependencies:** What does it depend on?
4. **Risk:** What could go wrong?
5. **Testing:** How much testing needed?

## Size vs Priority
- **Size** = effort/complexity
- **Priority** = importance/urgency
- A small task (XS) can be high priority (P0)
- A large task (XL) can be low priority (P3)

## Estimation Techniques

### 1. Analogous Estimation
Compare to similar past tasks
- "This looks like last week's M task"

### 2. Three-Point Estimation
- Best case (optimistic)
- Worst case (pessimistic)  
- Most likely
- Use formula: (Best + 4×Most Likely + Worst) ÷ 6

### 3. Planning Poker
For team estimation:
- Each member gives size estimate
- Discuss discrepancies
- Reach consensus

## Tracking & Improvement

### Metrics to Track:
1. **Estimation Accuracy:** Actual vs estimated size
2. **Size Distribution:** % of tasks by size
3. **Breakdown Rate:** % of XL tasks broken down
4. **Overrun Rate:** % of tasks exceeding estimate

### Improvement Process:
1. Monthly review of sizing accuracy
2. Adjust sizing guidelines based on data
3. Calibrate team estimation skills
4. Update examples based on experience

## Common Pitfalls

### Underestimating:
- Forgetting testing time
- Ignoring review cycles
- Overlooking dependencies
- Assuming perfect conditions

### Overestimating:
- Padding too much
- Including unrelated work
- Counting ideal time vs real time
- Not breaking down sufficiently

## Quick Reference Card

```
XS (<1h):    Trivial changes, docs, config
S (1-4h):    Simple features, basic bugs
M (4-8h):    Moderate complexity, integration
L (8-16h):   High complexity, cross-cutting
XL (16+h):   Epic work - MUST BREAK DOWN

Rules:
1. When in doubt, size up
2. Break down XL tasks
3. Consider all factors (complexity, uncertainty, etc.)
4. Track actual vs estimate
5. Learn and improve
```

## Template for Size Justification
When estimating, include brief justification:

```
**Size:** M (estimate)
**Justification:** 
- Requires changes to 3 components
- Needs integration testing
- Moderate uncertainty in API response format
- Similar to previous M-sized task
```