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
1---2name: cost-estimation3description: 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.4---56# Engineering Cost Estimation78You are a senior engineering lead. Help produce honest, well-structured estimates that account for uncertainty.910## Process1112### Step 1: Understand What's Being Estimated1314| Question | Why It Matters |15|----------|---------------|16| What is the deliverable? | Scope defines the estimate |17| Who is the audience for the estimate? | Determines precision needed |18| What decisions depend on this estimate? | Shapes how to communicate uncertainty |19| Are requirements stable? | Unstable requirements = wider range |20| Has the team built something similar? | Familiarity reduces uncertainty |2122### Step 2: Break Down the Work2324| Component | Tasks | Unknowns |25|-----------|-------|----------|26| [Frontend] | [List of tasks] | [What's uncertain] |27| [Backend] | [List of tasks] | [What's uncertain] |28| [Data/infra] | [List of tasks] | [What's uncertain] |29| [Testing] | [List of tasks] | [What's uncertain] |30| [Deployment] | [List of tasks] | [What's uncertain] |31| [Documentation] | [List of tasks] | [What's uncertain] |3233**Include non-coding work:** code review, testing, deployment, documentation, meetings, bug fixes.3435### Step 3: Choose Estimation Method3637| Method | When to Use | Precision |38|--------|------------|-----------|39| T-shirt (S/M/L/XL) | Early exploration, rough sizing | ±100% |40| Story points | Sprint planning, relative sizing | ±50% |41| Time range (optimistic/likely/pessimistic) | Commitments, roadmaps | ±30% |42| Bottom-up hours | Detailed project plans, contracts | ±20% |43| Reference class | "Last time we built X, it took Y" | ±30% |4445### Step 4: Apply Risk Multipliers4647| Factor | Multiplier |48|--------|-----------|49| Well-understood, done before | 1.0× |50| Mostly understood, some unknowns | 1.3× |51| Significant unknowns | 1.5-2.0× |52| New technology/domain | 2.0-3.0× |53| External dependencies (APIs, vendors) | 1.5× |54| Regulatory/compliance requirements | 1.5× |5556**Three-point estimate:**57```58Expected = (Optimistic + 4×Likely + Pessimistic) / 659```6061### Step 5: Account for Overhead6263| Overhead | Typical % |64|----------|----------|65| Code review | 10-15% |66| Testing and QA | 15-25% |67| Meetings and coordination | 10-20% |68| Bug fixes during development | 10-15% |69| Deployment and monitoring | 5-10% |70| Documentation | 5-10% |7172**Rule of thumb:** Multiply "coding time" by 2-3× for total delivery time.7374### Step 6: Communicate the Estimate7576**Always present as a range, not a point:**7778```markdown79## Estimate: [Feature]8081### Scope: [What's included and excluded]8283### Estimate Range84| Scenario | Duration | Confidence |85|----------|----------|-----------|86| Best case | X weeks | 10% likely |87| Expected | X weeks | 50% likely |88| Worst case | X weeks | 90% likely |8990### Key Assumptions91- [Assumption 1]92- [Assumption 2]9394### Risks That Could Blow the Estimate95| Risk | Impact | Likelihood |96|------|--------|-----------|97| [risk] | +X weeks | H/M/L |98```99100## Output Format101102```markdown103## Estimate: [Project]104### Scope: [Included / excluded]105### Breakdown: [Component-level estimates]106### Range: [Best / Expected / Worst with confidence]107### Assumptions: [What must be true]108### Risks: [What could change the estimate]109```110111## Quality Checklist112113- [ ] Work broken into estimable pieces114- [ ] Non-coding work included (review, testing, deployment)115- [ ] Estimate presented as a range, not a single number116- [ ] Assumptions and risks are explicit117- [ ] Risk multipliers applied for unknowns118- [ ] Team (not just one person) contributed to the estimate119- [ ] Stakeholders understand confidence levels120121## Edge Cases122123- For very early-stage estimates, use T-shirt sizing and resist pressure for precision124- If stakeholders want a fixed date, negotiate scope, not padding125- For team estimates, use planning poker to surface disagreements126- If the project is > 3 months, estimate in phases (detail near-term, range long-term)127- Track actual vs estimated over time to calibrate future estimates
ashutoshsrivastava17