Estimation

Estimation

> Part of the discovery-phase skill pack · scoping group · reads discovery-context.md (run profile-builder first if missing).

Agency-style estimation: effort by discipline × phase, with low / expected / high ranges, and a list of assumptions that, if violated, invalidate the estimate. The output is the heart of any commercial proposal.

Step 1 — Read context

Read discovery-context.md (sections 1. Client → Stage, 3. Engagement → Mode and Budget context, 6. Constraints) and scope-doc.md.

If discovery-context.md is missing, ask the BA inline: "(a) greenfield or migration; (b) fixed-fee or T&M?" — tag the output [ASSUMED ENGAGEMENT]. If scope-doc.md is missing, ask for in/out scope bullets per area, or fall back to a class-of-magnitude estimate (S / M / L / XL) tagged [NO-SCOPE] — not for client use without a follow-up proper estimate. Never block; recommend profile-builder / feature-scoping for high-stakes work.

Step 2 — Pick estimation method

Match to engagement timeline + scope size:

| Method | When | Effort to produce | |---|---|---| | 3-point parametric | Standard for proposals; S/M/L scopes | 30-60 min | | Bottom-up by user story | Detailed scope, large engagement | 2-4 hours | | Reference-class ("we did X for Y, multiply by Z") | Repeat engagement, similar scope | 15-30 min | | Phased gates | Long engagement; only first phase precise | 30 min for phase 1, range for rest |

Default to 3-point parametric for discovery-phase outputs.

Step 3 — Discipline × Phase matrix

Build the matrix. Adapt phases to engagement mode:

| Phase \ Discipline | BA | PM | Design | Dev (FE) | Dev (BE) | QA | DevOps | Total | |---|---|---|---|---|---|---|---|---| | Discovery follow-ups | | | | | | | | | | Design (wireframe → high-fi) | | | | | | | | | | Build phase 1 | | | | | | | | | | Build phase 2 | | | | | | | | | | QA / hardening | | | | | | | | | | Launch / handoff | | | | | | | | | | Total per discipline | | | | | | | | |

Numbers are person-hours or person-days. Pick one unit and stick to it.

Step 4 — Three-point ranges

For every cell with non-trivial effort, capture:

• Low — best case, no surprises
• Expected — most likely
• High — top 10% case (NOT worst case — worst case is "kill")

Total each row and column. Sum row totals = sum of column totals = grand total (sanity check).

Step 5 — Apply uncertainty multipliers

Per discipline, apply a multiplier reflecting estimate confidence:

| Confidence | Multiplier on Expected | |---|---| | Done this exact thing before | 1.0 | | Familiar pattern, slight variation | 1.2 | | Familiar tech, new domain | 1.5 | | New tech + new domain | 2.0 | | Bleeding edge / heavy R&D | 3.0 |

Show both raw and adjusted totals.

Step 6 — Assumptions that invalidate the estimate

A bullet list of what must be true. If any becomes false, the estimate is void and re-estimation is required.

Typical:

• Scope-doc remains stable (no mid-build scope additions)
• Client provides decisions within 2 business days
• Existing tech stack: ``
• Auth uses existing SSO (no new identity provider)
• Data volume below ``
• Third-party APIs: `` available with documented contracts
• Design assets / brand guidelines provided by client
• Single time zone overlap of 4+ hours daily

Step 7 — Risk-driven contingency

Pull from risk-assumption-map.md (if present) the rows tagged [agency] or [shared]. For each, add a contingency line item:

| Risk | If realized, additional effort | Owner | |---|---|---|

This becomes the basis for proposal "contingency budget" or T&M risk-pool conversations.

Step 8 — Format for downstream skills

Format the output so proposal can pull headline numbers + assumption list verbatim, and sow-draft can pull the matrix + risk register.

Output

./discovery/estimation.md per ./template.md.

Append to _log.md: [estimation | YYYY-MM-DD] method: ; total: ; multiplier: ; contingency: .

Anti-patterns

• Single-number estimate. Always 3-point. Stakeholders read the single number as a commitment.
• No assumption list. An estimate without listed assumptions = a commitment. Different commercial implications.
• Padding via vague "buffer". Be specific: "+20% because new domain", not "+20% buffer".
• Estimating by hours when budget is in days. Match the unit the client thinks in.
• Hiding contingency. If risks are real, name them with their cost. Hidden buffers fund themselves with worse risks later.
• Estimating without a scope-doc. Strongly preferred to run feature-scoping first; if you proceed via inline bootstrap, the estimate inherits any vagueness in the bullets — keep it tagged DRAFT-ONLY until a real scope doc exists.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: stanislavnianko
• Source: stanislavnianko/product-discovery-claude-skills
• License: MIT

Install and usage instructions live in the source repository linked above.