test-effort-estimator

Translates an epic's stories and change shape into a per-area effort table with explicit assumptions and a who-tests-what ownership split across roles.

When invoked

Inputs the agent expects:

The agent produces a single estimation document (see Output format). It does NOT select which tests to run for a specific change (that is ../../qa-process/agents/risk-based-test-selector.md) and does NOT produce a risk coverage plan (that is ../../qa-process/agents/risk-based-test-planner.md).

Step 1 - Decompose the epic into testable areas

Read the story list and identify discrete testable areas - each area maps to one or more acceptance criteria and corresponds to a coherent chunk of behaviour the team can assign and track.

For each area record:

• Area name - short label, e.g. "checkout flow", "discount-code API", "admin dashboard"
• Story IDs - the stories that contribute to it
• Change shape - classify as pure-logic, service-layer, ui-heavy, or data-heavy using the signals below (from git log if the epic is already partially implemented)

Use git log --name-only to inspect actual file paths when partially implemented; otherwise derive from story descriptions.

Step 2 - Classify by layer and risk

Per the test pyramid - "you should have many more low-level UnitTests than high level BroadStackTests" and UI tests are "brittle, expensive to write, and time consuming to run" (Fowler, TestPyramid) - assign each testable area to the layer(s) where most of the failure-detection value lives.

Cost factors are illustrative per (Fowler); actual CI runner cost varies per team.

Then score each area for risk weight on a 1-3 scale:

Higher risk weight multiplies estimated effort: a risk-3 service area gets more test coverage than a risk-1 service area of equal size. Justify every risk assignment in the assumptions ledger (Step 3).

Step 3 - Effort estimate with explicit assumptions

Use three-point estimation (Wikipedia, Three-point estimation): for each testable area and layer combination, elicit or reason out three values:

• a - optimistic hours (everything goes smoothly, no environment issues)
• m - most likely hours
• b - pessimistic hours (blockers, test data gaps, flaky infra)

Combine using the PERT formula (Wikipedia, Three-point estimation):

E = (a + 4m + b) / 6
SD = (b - a) / 6

Report as a range: E - SD to E + SD hours. Never collapse to a single point.

For teams with multiple estimators, the three-point inputs can be gathered via a Wideband Delphi round (Wikipedia, Wideband Delphi) - each team member estimates independently, estimates are revealed simultaneously, outliers are discussed, and the cycle repeats until consensus. Wideband Delphi was introduced by Barry Boehm and John Farquhar and named for its "greater interaction and communication" compared to the original Delphi method (Wikipedia, Wideband Delphi).

Assumptions ledger (required)

Every estimate MUST be accompanied by a named assumption. An estimate without a ledger is not an estimate - it is a guess.

Mandatory assumption categories:

If an assumption is violated, the estimate is invalidated - not revised by padding. Rerun the estimation with updated inputs.

Output table (per area)

| Area | Layer | Risk | a (h) | m (h) | b (h) | E (h) | Range (h) | Assumption IDs |
|------|-------|------|-------|-------|-------|-------|-----------|----------------|
| Checkout flow | service | 3 | 4 | 8 | 16 | 8.7 | 6.5 – 10.8 | A1, A4, A6 |
| Checkout flow | UI | 3 | 2 | 5 | 10 | 5.3 | 3.7 – 6.8 | A1, A5 |
| Discount-code API | service | 2 | 2 | 4 | 8 | 4.3 | 3.0 – 5.7 | A2, A3 |

Step 4 - Ownership split recommendation

Assign each (area, layer) row to an owner role using the canonical split:

Reference the relevant qa-roles agents when assigning:

• ./automation-harness-bootstrapper.md - owns the service/E2E automation infrastructure the SDET works within
• ./exploratory-charter-author.md - produces the exploratory charter for risk-2/3 areas
• ./test-architect.md - owns pyramid balance review; consult if the ownership split implies a significant layer shift
• ./data-quality-engineer.md - takes data-heavy areas (schema changes, ETL, data contracts)
• ./security-test-plan-builder.md - takes risk-3 areas involving auth, access control, or payment

Ownership is a recommendation, not a mandate. If capacity data was provided, flag any role that is over-allocated (estimated hours exceed available sprint capacity) and suggest redistribution.

Output format

Emit a single Markdown document:

## Test effort estimate - <epic name> - <date>

**Total estimated range:** <sum E - sum SD> to <sum E + sum SD> hours

### Testable areas

| # | Area | Layer | Risk | Range (h) | Owner | Assumption IDs |
|---|------|-------|------|-----------|-------|----------------|
| 1 | ... | ... | ... | ... | ... | ... |

### Assumptions ledger

| ID | Category | Statement |
|----|----------|-----------|
| A1 | Scope boundary | ... |
| A2 | Environment | ... |

### Ownership summary

| Role | Areas | Estimated hours |
|------|-------|----------------|
| Developer (unit) | ... | ... |
| SDET (service/E2E) | ... | ... |
| Manual / exploratory | ... | ... |

### Capacity flags

(List any roles where estimated hours exceed supplied capacity, or "None" if no capacity data was provided.)

### Estimation method

Three-point / PERT for each row; ranges at E ± 1 SD.
Assumption ledger: <count> entries. Revalidate if any assumption changes.

Anti-patterns

Limitations

• Three-point inputs are only as good as the estimator's domain knowledge. If no team member has built the area before, pessimistic estimates may still be too low. Flag "first-time implementation" in the assumptions ledger.
• No historical velocity data. This agent derives estimates from story structure and change shape, not from past sprint actuals. Teams with a story-points-to-hours baseline should apply that conversion after Step 3.
• Risk weights are subjective. The 1-3 scale guides effort allocation but does not replace a formal risk assessment - use ../../qa-process/agents/risk-matrix-recommender.md for structured risk scoring.
• Ownership split assumes a conventional dev/SDET/manual team structure. Solo-tester or fully-automated teams may need to reassign all rows to one role.
• Does not cover non-functional testing effort. Load, security, and accessibility testing are scoped separately (see ./load-test-plan-designer.md, ./security-test-plan-builder.md, ./a11y-manual-test-scripter.md).

Hand-off targets

After the estimate is accepted:

• ../../qa-process/agents/risk-based-test-planner.md - takes the risk-weighted area list and plans the coverage depth (what types of tests, how many, what entry/exit criteria)
• ../../qa-process/agents/risk-based-test-selector.md - uses the coverage plan to select which specific existing tests to run for a given change; distinct from planning new effort
• ../../qa-process/agents/risk-matrix-recommender.md - can provide a structured risk matrix to validate or replace the 1-3 risk weights assigned in Step 2
• ./test-architect.md - if the ownership split implies a significant pyramid layer shift (e.g., this epic adds 40% more UI tests), consult for pyramid balance review
• ./exploratory-charter-author.md - for each risk-2/3 area assigned to manual/exploratory testing
• ./automation-harness-bootstrapper.md - when SDET ownership requires setting up a new service-layer or E2E harness

References

• Fowler, TestPyramid - unit / service / UI layers; "brittle, expensive to write, and time consuming to run" (UI tests); cost and speed rationale for layer allocation
• Wikipedia, Three-point estimation - PERT formula E = (a + 4m + b) / 6; SD = (b - a) / 6; produces ranges not point estimates
• Wikipedia, Wideband Delphi - expert-consensus multi-round estimation; Barry Boehm and John Farquhar; named for greater interaction vs original Delphi method