# Estimation

> Estimate project scope, timeline, and resource requirements using multiple estimation techniques including bottom-up, top-down, and analogous estimation methods for accurate project planning.

- Skill: `senior-sigan/estimation` (Agent Skill)
- Install (CLI): `npx skillmds@latest add senior-sigan/estimation`
- Raw SKILL.md: https://api.skillmd.com/api/skills/senior-sigan/estimation/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: senior-sigan (https://skillmd.com/u/senior-sigan)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/senior-sigan/estimation

---


# Estimation Guide

Detailed techniques for accurate effort estimation in technical roadmaps.

## The Estimation Problem

Humans are notoriously bad at estimation, especially for:
- Novel work (never done before)
- Complex work (many unknowns)
- Long-duration work (> 2 weeks)

This guide provides techniques to improve accuracy.

---

## T-Shirt Sizing Deep Dive

### Size Definitions

| Size | Points | Duration | Characteristics | Example |
|------|--------|----------|-----------------|---------|
| **XS** | 1 | 2-4 hours | Config change, copy update, trivial fix | Change environment variable |
| **S** | 2 | 0.5-1 day | Simple, well-understood, no dependencies | Add new API field |
| **M** | 3 | 1-2 days | Some complexity, minor unknowns | Build CRUD endpoint |
| **L** | 5 | 3-5 days | Complex, research needed | Implement authentication |
| **XL** | 8 | 1-2 weeks | Very complex, significant unknowns | Build recommendation engine |
| **XXL** | 13+ | > 2 weeks | Must be broken down | Full microservice |

### When to Use Each Size

**XS - Trivial**
- You've done this exact thing before
- No code review concerns
- Can be done and deployed in one sitting

**S - Simple**
- Clear implementation path
- Single component affected
- Standard patterns apply

**M - Standard**
- Normal feature work
- May need some research
- Touches 2-3 files/components

**L - Complex**
- Multiple components affected
- Integration work required
- Some architectural decisions

**XL - Very Complex**
- Significant unknowns
- New technology/patterns
- Cross-team coordination
- Should consider breaking down

**XXL - Epic-level**
- Too large for single story
- Must be decomposed
- Red flag if assigned to single item

---

## Estimation Techniques

### 1. Reference-Based Estimation

Compare to similar past work:

```
Previous similar feature: 3 weeks
Complexity adjustment: 1.2x (slightly more complex)
Team familiarity: 0.9x (more familiar now)
Estimate: 3 × 1.2 × 0.9 = 3.2 weeks
```

### 2. Task Decomposition

Break down until tasks are < 1 day:

```
Feature: User Dashboard

Tasks:
├── Design API schema (S: 4h)
├── Implement backend endpoint (M: 8h)
├── Create React components (M: 12h)
├── Write unit tests (S: 4h)
├── Integration tests (S: 4h)
├── Documentation (XS: 2h)
└── Code review + fixes (S: 4h)

Total: 38 hours ≈ 5 days
Add 25% buffer: 6.25 days
Estimate: L (3-5 days) → round up to 1.5 weeks
```

### 3. Three-Point Estimation

Estimate optimistic, most likely, and pessimistic:

```
Optimistic (O): Everything goes perfectly = 3 days
Most Likely (M): Normal development = 5 days
Pessimistic (P): Everything goes wrong = 12 days

PERT Estimate = (O + 4M + P) / 6
             = (3 + 20 + 12) / 6
             = 5.8 days
```

### 4. Planning Poker

Team-based estimation:
1. Present story to team
2. Everyone estimates privately
3. Reveal estimates simultaneously
4. Discuss outliers
5. Re-estimate until consensus

---

## Adjustment Factors

### Multipliers to Apply

| Factor | Multiplier | When to Apply |
|--------|------------|---------------|
| **New technology** | 1.5x | Team hasn't used tech before |
| **New team member** | 1.3x | < 3 months on project |
| **External dependency** | 1.2x | Per external team/service |
| **Legacy code** | 1.4x | Poorly documented old code |
| **Compliance requirements** | 1.3x | Security/audit requirements |
| **Cross-timezone** | 1.2x | Team spans > 6 hour difference |

### Velocity Adjustments

```
Theoretical capacity:
  5 engineers × 40 hours = 200 hours/week

Realistic capacity (apply factors):
  - Meetings/admin: 0.8x
  - Context switching: 0.85x
  - Interruptions: 0.9x
  - Learning/research: 0.9x

Effective capacity:
  200 × 0.8 × 0.85 × 0.9 × 0.9 = 110 hours/week

That's 55% of theoretical!
```

---

## Common Estimation Mistakes

### 1. The 90% Done Trap
**Mistake**: "We're 90% done" for weeks.
**Fix**: Track tasks to completion, not percentage.

### 2. Ignoring Integration
**Mistake**: Estimate components in isolation.
**Fix**: Add explicit integration tasks and testing.

### 3. Happy Path Only
**Mistake**: Estimate assumes no bugs, no blockers.
**Fix**: Always add 20-30% buffer.

### 4. Scope Creep Blindness
**Mistake**: Estimate original scope, deliver expanded scope.
**Fix**: Re-estimate when scope changes.

### 5. Anchoring
**Mistake**: First estimate biases all subsequent estimates.
**Fix**: Use planning poker, estimate independently first.

### 6. Planning Fallacy
**Mistake**: Optimism despite past evidence.
**Fix**: Compare to actual duration of past similar work.

---

## Estimation for Different Phases

### Phase 1: MVP
- Estimate in detail (story/task level)
- Add 25% buffer
- Expect 20% scope change

### Phase 2: Scale
- Estimate at epic level
- Add 30% buffer
- Expect 30% scope change

### Phase 3: Advanced
- Estimate at theme level only
- Add 40% buffer
- Expect 50% scope change

---

## Team Velocity

### Calculating Historical Velocity

```
Sprint 1: 34 points completed
Sprint 2: 28 points completed
Sprint 3: 31 points completed
Sprint 4: 35 points completed

Average velocity: 32 points/sprint
Standard deviation: 2.9 points

Conservative estimate: 29 points/sprint (avg - 1 std dev)
```

### Using Velocity for Planning

```
Total backlog: 180 points
Conservative velocity: 29 points/sprint
Sprints needed: 180 / 29 = 6.2 sprints

Add buffer (20%): 7.5 sprints
Estimate: 8 sprints (4 months with 2-week sprints)
```

---

## Estimation Checklist

Before finalizing estimates, verify:

- [ ] Broke down items to < 1 week
- [ ] Considered integration time
- [ ] Accounted for testing
- [ ] Included documentation
- [ ] Added code review time
- [ ] Applied technology multipliers
- [ ] Compared to past similar work
- [ ] Added 20-30% buffer
- [ ] Team agreed on estimates
- [ ] Identified dependencies