# Realistic Time Estimation — Development Guidelines

> **Agent role**: **DO NOT MAKE TIME ESTIMATES**. Instead, use phases,
> milestones, and complexity levels. Time estimates are consistently wrong
> and create unrealistic expectations.

## Purpose

Development time estimates are consistently wrong and create unrealistic
expectations. This rule ensures we focus on phases, milestones, and
complexity rather than trying to predict specific timeframes.

## Critical Rule

**NEVER provide specific time estimates** (hours, days, weeks) for
development tasks. Instead, use:

- **Complexity levels** (Low, Medium, High, Critical)

- **Phases and milestones** with clear acceptance criteria

- **Platform-specific considerations** (Web, Mobile, Desktop)

- **Testing requirements** and validation steps

## Planning Framework

### Complexity Assessment

- **Low**: Simple changes, existing patterns, minimal testing

- **Medium**: New features, moderate testing, some integration

- **High**: Complex features, extensive testing, multiple platforms

- **Critical**: Core architecture changes, full regression testing

### Platform Categories

- **Web**: Browser compatibility, responsive design, accessibility

- **Mobile**: Native APIs, platform-specific testing, deployment

- **Desktop**: Electron integration, system APIs, distribution

### Testing Strategy

- **Unit tests**: Core functionality validation

- **Integration tests**: Component interaction testing

- **E2E tests**: User workflow validation

- **Platform tests**: Cross-platform compatibility

## Process Guidelines

### Planning Phase

1. **Scope Definition**: Clear requirements and acceptance criteria

2. **Complexity Assessment**: Evaluate technical and business complexity

3. **Phase Breakdown**: Divide into logical, testable phases

4. **Milestone Definition**: Define success criteria for each phase

### Execution Phase

1. **Phase 1**: Foundation and core implementation

2. **Phase 2**: Feature completion and integration

3. **Phase 3**: Testing, refinement, and documentation

4. **Phase 4**: Deployment and validation

### Validation Phase

1. **Acceptance Testing**: Verify against defined criteria

2. **Platform Testing**: Validate across target platforms

3. **Performance Testing**: Ensure performance requirements met

4. **Documentation**: Update relevant documentation

## Remember

**Your first estimate is wrong. Your second estimate is probably still
wrong. Focus on progress, not deadlines.**

---

**See also**:

- `.cursor/rules/development/planning_examples.mdc` for detailed planning examples

- `.cursor/rules/development/complexity_assessment.mdc` for complexity evaluation

**Status**: Active development guidelines
**Priority**: High
**Estimated Effort**: Ongoing reference
**Dependencies**: None
**Stakeholders**: Development team, Project managers

## Model Implementation Checklist

### Before Time Estimation

- [ ] **Requirements Analysis**: Understand all requirements and acceptance criteria
- [ ] **Complexity Assessment**: Evaluate technical and business complexity
- [ ] **Platform Review**: Identify requirements across all target platforms
- [ ] **Stakeholder Input**: Gather input from all affected parties

### During Time Estimation

- [ ] **Phase Breakdown**: Divide work into logical, testable phases
- [ ] **Complexity Classification**: Assign complexity levels (Low/Medium/High/Critical)
- [ ] **Platform Considerations**: Account for platform-specific requirements
- [ ] **Testing Strategy**: Plan comprehensive testing approach

### After Time Estimation

- [ ] **Milestone Definition**: Define success criteria for each phase
- [ ] **Progress Tracking**: Set up monitoring and tracking mechanisms
- [ ] **Documentation**: Document estimation process and assumptions
- [ ] **Stakeholder Communication**: Share estimation approach and progress focus