project-planning

What this skill does

# Project Planning

This skill provides comprehensive guidance for planning and managing software development projects effectively.

## Work Breakdown Structure (WBS)

### Breaking Down Large Projects

```markdown
Project: E-commerce Platform
├── 1. User Management
│   ├── 1.1 Authentication
│   │   ├── 1.1.1 Email/Password Login
│   │   ├── 1.1.2 Social Login (Google, Facebook)
│   │   └── 1.1.3 Password Reset
│   ├── 1.2 User Profiles
│   │   ├── 1.2.1 Profile Creation
│   │   ├── 1.2.2 Profile Editing
│   │   └── 1.2.3 Avatar Upload
│   └── 1.3 Role Management
│       ├── 1.3.1 Admin Role
│       ├── 1.3.2 Customer Role
│       └── 1.3.3 Vendor Role
├── 2. Product Catalog
│   ├── 2.1 Product Listings
│   ├── 2.2 Product Details
│   ├── 2.3 Product Search
│   └── 2.4 Product Categories
├── 3. Shopping Cart
│   ├── 3.1 Add to Cart
│   ├── 3.2 Update Quantities
│   ├── 3.3 Remove Items
│   └── 3.4 Cart Persistence
├── 4. Checkout
│   ├── 4.1 Shipping Address
│   ├── 4.2 Payment Processing
│   ├── 4.3 Order Confirmation
│   └── 4.4 Email Notifications
└── 5. Order Management
    ├── 5.1 Order History
    ├── 5.2 Order Tracking
    └── 5.3 Order Cancellation
```

### WBS Best Practices

**1. Start with deliverables, not activities**
```markdown
❌ Wrong (activities):
- Write code
- Test features
- Deploy

✅ Right (deliverables):
- User Authentication System
- Product Search Feature
- Payment Integration
```

**2. Use the 8/80 rule**
- No task should take less than 8 hours (too granular)
- No task should take more than 80 hours (too large)
- Sweet spot: 1-5 days per task

**3. Break down until you can estimate**
```markdown
❌ Too vague:
- Build API (? days)

✅ Specific:
- Design API endpoints (1 day)
- Implement authentication (2 days)
- Create CRUD operations (3 days)
- Write API documentation (1 day)
- Add rate limiting (1 day)
Total: 8 days
```

## Task Estimation

### Story Points

**Fibonacci Scale**: 1, 2, 3, 5, 8, 13, 21

```markdown
1 point - Trivial
- Update documentation
- Fix typo
- Change button color

2 points - Simple
- Add validation to form field
- Create simple API endpoint
- Write unit tests for existing function

3 points - Moderate
- Implement login form
- Add pagination to list
- Create database migration

5 points - Complex
- Build user profile page
- Implement search functionality
- Add email notifications

8 points - Very Complex
- Build payment integration
- Implement complex reporting
- Create admin dashboard

13 points - Epic
- Build entire authentication system
- Create complete checkout flow
(Should be broken down further)
```

### T-Shirt Sizing

**Quick estimation for early planning**:

```markdown
XS (1-2 days)
- Bug fixes
- Minor UI updates
- Documentation updates

S (3-5 days)
- Small features
- Simple integrations
- Basic CRUD operations

M (1-2 weeks)
- Medium features
- Standard integrations
- Multiple related stories

L (2-4 weeks)
- Large features
- Complex integrations
- Multiple epics

XL (1-2 months)
- Major features
- System redesigns
(Should be broken down into smaller pieces)
```

### Planning Poker

**Collaborative estimation process**:

```markdown
1. Product Owner presents user story
2. Team asks clarifying questions
3. Each member privately selects estimate
4. All reveal simultaneously
5. Discuss differences (especially highest/lowest)
6. Re-estimate if needed
7. Reach consensus

Example Session:
Story: "As a user, I want to reset my password"

Round 1 Estimates: 2, 3, 3, 8, 3
Discussion: Why 8?
- "What about email templates?"
- "What if SMTP fails?"
- "Need password strength validation"

Round 2 Estimates: 5, 5, 5, 5, 5
Consensus: 5 points
```

### Estimation Accuracy

**Cone of Uncertainty**:
```
Project Start: ±100% accuracy
Requirements: ±50% accuracy
Design: ±25% accuracy
Development: ±10% accuracy
Testing: ±5% accuracy
```

**Build in buffer**:
```markdown
Optimistic: 3 days
Realistic: 5 days
Pessimistic: 8 days

Formula: (Optimistic + 4×Realistic + Pessimistic) ÷ 6
Buffer: (3 + 4×5 + 8) ÷ 6 = 5.2 days

Use 6 days for planning
```

## Dependency Identification

### Types of Dependencies

```markdown
1. Finish-to-Start (FS) - Most common
   Task B cannot start until Task A finishes
   Example: Design → Development

2. Start-to-Start (SS)
   Task B cannot start until Task A starts
   Example: Development → Code Review (parallel)

3. Finish-to-Finish (FF)
   Task B cannot finish until Task A finishes
   Example: Development → Testing (testing continues)

4. Start-to-Finish (SF) - Rare
   Task B cannot finish until Task A starts
   Example: Old system → New system (overlap)
```

### Dependency Mapping

```markdown
Task Dependencies:

1. Database Schema Design
   └─► 2. API Development (FS)
       ├─► 3. Frontend Development (FS)
       └─► 4. Integration Tests (SS)
           └─► 5. End-to-End Tests (FS)

2. API Development
   └─► 6. API Documentation (SS)

3. Frontend Development
   └─► 7. UI/UX Review (FF)

Critical Path: 1 → 2 → 3 → 5
(Longest path through dependencies)
```

### Managing Dependencies

```typescript
// Dependency tracking in code
interface Task {
  id: string;
  name: string;
  dependencies: string[]; // IDs of tasks that must complete first
  status: 'pending' | 'in-progress' | 'completed' | 'blocked';
}

const tasks: Task[] = [
  {
    id: 'db-schema',
    name: 'Design database schema',
    dependencies: [],
    status: 'completed',
  },
  {
    id: 'api-dev',
    name: 'Develop API',
    dependencies: ['db-schema'],
    status: 'in-progress',
  },
  {
    id: 'frontend-dev',
    name: 'Develop frontend',
    dependencies: ['api-dev'],
    status: 'blocked', // Waiting for API
  },
];

function canStartTask(taskId: string): boolean {
  const task = tasks.find(t => t.id === taskId);
  if (!task) return false;

  // Check if all dependencies are completed
  return task.dependencies.every(depId => {
    const dep = tasks.find(t => t.id === depId);
    return dep?.status === 'completed';
  });
}
```

## Critical Path Analysis

### Finding the Critical Path

```markdown
Project: Launch Marketing Website

Tasks:
A. Design mockups (3 days)
B. Develop frontend (5 days) - depends on A
C. Write content (4 days) - independent
D. Set up hosting (1 day) - independent
E. Deploy website (1 day) - depends on B, C, D
F. Test website (2 days) - depends on E

Path 1: A → B → E → F = 3 + 5 + 1 + 2 = 11 days
Path 2: C → E → F = 4 + 1 + 2 = 7 days
Path 3: D → E → F = 1 + 1 + 2 = 4 days

Critical Path: A → B → E → F (11 days)
(Any delay in these tasks delays the entire project)
```

### Managing Critical Path

```markdown
Strategies:

1. Fast-track critical tasks
   - Assign best developers
   - Remove blockers immediately
   - Daily status checks

2. Crash critical tasks (add resources)
   - Pair programming
   - Additional team members
   - Overtime (carefully)

3. Parallelize where possible
   - Content writing during development
   - Documentation during testing

4. Monitor closely
   - Daily updates on critical path
   - Early warning of delays
   - Quick decision-making
```

## Risk Assessment and Mitigation

### Risk Matrix

```markdown
Impact vs Probability:

        Low         Medium        High
High    Monitor     Mitigate      Immediate Action
Medium  Accept      Monitor       Mitigate
Low     Accept      Accept        Monitor

Example Risks:

1. API Integration Delays (High Impact, Medium Probability)
   → Mitigate: Start integration early, have backup plan

2. Key Developer Leaves (High Impact, Low Probability)
   → Monitor: Document knowledge, cross-train team

3. Library Deprecated (Medium Impact, Low Probability)
   → Accept: Will address if it happens
```

### Risk Register

```markdown
| ID | Risk | Impact | Prob | Status | Mitigation |
|----|------|--------|------|--------|------------|
| R1 | Third-party API unreliable | High | Medium | Active | Build fallback, cache responses |
| R2 | Database performance issues | High | Low | Monitor | Load testing, optimization plan |
| R3 | Req