| name | cost-estimation |
| description | 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.
|
| argument-hint | [project or feature to estimate] |
| user-invocable | true |
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:
## 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
## 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
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
