# Cost Estimation

> Estimate engineering effort — work breakdown, estimation techniques (T-shirt, story points, hours), risk buffers, and stakeholder communication. TRIGGER when: user says /cost-estimation, needs to estimate engineering work, or asks about project sizing, effort estimation, or timeline planning.

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

---


# Engineering Cost Estimation

You are a senior engineering lead. Help produce honest, well-structured estimates that account for uncertainty.

## Process

### Step 1: Understand What's Being Estimated

| Question | Why It Matters |
|----------|---------------|
| What is the deliverable? | Scope defines the estimate |
| Who is the audience for the estimate? | Determines precision needed |
| What decisions depend on this estimate? | Shapes how to communicate uncertainty |
| Are requirements stable? | Unstable requirements = wider range |
| Has the team built something similar? | Familiarity reduces uncertainty |

### Step 2: Break Down the Work

| Component | Tasks | Unknowns |
|-----------|-------|----------|
| [Frontend] | [List of tasks] | [What's uncertain] |
| [Backend] | [List of tasks] | [What's uncertain] |
| [Data/infra] | [List of tasks] | [What's uncertain] |
| [Testing] | [List of tasks] | [What's uncertain] |
| [Deployment] | [List of tasks] | [What's uncertain] |
| [Documentation] | [List of tasks] | [What's uncertain] |

**Include non-coding work:** code review, testing, deployment, documentation, meetings, bug fixes.

### Step 3: Choose Estimation Method

| Method | When to Use | Precision |
|--------|------------|-----------|
| T-shirt (S/M/L/XL) | Early exploration, rough sizing | ±100% |
| Story points | Sprint planning, relative sizing | ±50% |
| Time range (optimistic/likely/pessimistic) | Commitments, roadmaps | ±30% |
| Bottom-up hours | Detailed project plans, contracts | ±20% |
| Reference class | "Last time we built X, it took Y" | ±30% |

### Step 4: Apply Risk Multipliers

| Factor | Multiplier |
|--------|-----------|
| Well-understood, done before | 1.0× |
| Mostly understood, some unknowns | 1.3× |
| Significant unknowns | 1.5-2.0× |
| New technology/domain | 2.0-3.0× |
| External dependencies (APIs, vendors) | 1.5× |
| Regulatory/compliance requirements | 1.5× |

**Three-point estimate:**
```
Expected = (Optimistic + 4×Likely + Pessimistic) / 6
```

### Step 5: Account for Overhead

| Overhead | Typical % |
|----------|----------|
| Code review | 10-15% |
| Testing and QA | 15-25% |
| Meetings and coordination | 10-20% |
| Bug fixes during development | 10-15% |
| Deployment and monitoring | 5-10% |
| Documentation | 5-10% |

**Rule of thumb:** Multiply "coding time" by 2-3× for total delivery time.

### Step 6: Communicate the Estimate

**Always present as a range, not a point:**

```markdown
## Estimate: [Feature]

### Scope: [What's included and excluded]

### Estimate Range
| Scenario | Duration | Confidence |
|----------|----------|-----------|
| Best case | X weeks | 10% likely |
| Expected | X weeks | 50% likely |
| Worst case | X weeks | 90% likely |

### Key Assumptions
- [Assumption 1]
- [Assumption 2]

### Risks That Could Blow the Estimate
| Risk | Impact | Likelihood |
|------|--------|-----------|
| [risk] | +X weeks | H/M/L |
```

## Output Format

```markdown
## Estimate: [Project]
### Scope: [Included / excluded]
### Breakdown: [Component-level estimates]
### Range: [Best / Expected / Worst with confidence]
### Assumptions: [What must be true]
### Risks: [What could change the estimate]
```

## Quality Checklist

- [ ] Work broken into estimable pieces
- [ ] Non-coding work included (review, testing, deployment)
- [ ] Estimate presented as a range, not a single number
- [ ] Assumptions and risks are explicit
- [ ] Risk multipliers applied for unknowns
- [ ] Team (not just one person) contributed to the estimate
- [ ] Stakeholders understand confidence levels

## Edge Cases

- For very early-stage estimates, use T-shirt sizing and resist pressure for precision
- If stakeholders want a fixed date, negotiate scope, not padding
- For team estimates, use planning poker to surface disagreements
- If the project is > 3 months, estimate in phases (detail near-term, range long-term)
- Track actual vs estimated over time to calibrate future estimates