Development Estimation
Purpose
Create consistent, defensible estimates by:
- Triaging and clarifying scope (especially for bug lists)
- Decomposing work into deliverable components
- Accounting for testing, QA, and release overhead
- Identifying risks and unknowns with explicit mitigation
- Producing confidence-based ranges (P50/P80/P90)
Optimized for reviewing an existing project or backlog and producing a realistic delivery forecast.
When to Use
- Estimating feature or project scope and delivery timelines
- Reviewing a backlog and producing a time estimate
- Producing risk-aware estimates with confidence intervals
- Converting a list of problems into an execution plan
Avoid When
- The task is trivial and a gut-check is sufficient
- Requirements are unknown and discovery is the real work
- You lack access to the codebase or requirements
Inputs Required
Provide as much as possible; estimate quality depends on clarity.
Minimum
- List of items (bugs/features) with short descriptions
- Target platform/environment (e.g., iOS/Android/Web, staging/prod)
- Constraints (deadline, must-fix vs can-slip)
Helpful
- Repro steps, logs, screenshots
- Architecture notes or codebase access
- Deployment pipeline and QA process
- Team capacity model (engineers, focus hours/day, meeting load)
- Definition of done (tests required, QA sign-off, release scope)
Estimation Frames
Always confirm the estimate frame up front:
- Effort: engineer-days or engineer-weeks
- Calendar: derived from capacity (effort / throughput)
- Cost: optional, requires rate assumptions
- Complexity: t-shirt sizing or points (only if requested)
Default Capacity Model
Unless provided, assume:
- 5–6 hours/day of effective build time per engineer
- Review and coordination overhead included per item
- QA/release overhead is stated explicitly as an assumption
Triage Rubric (Bug Backlog)
For each bug, capture:
Repro
- A: Always
- B: Sometimes / flaky
- C: Cannot repro / unclear
Clarity
- A: Clear cause or clear fix path
- B: Partial (needs investigation)
- C: Unknown (needs discovery)
Impact
- Blocker / High / Medium / Low
Fix Type
- UI / Backend / Infra / Data / Dependency / Config / Unknown
Risk Flags
- Concurrency / migrations / auth/security / payments / third-party API
- Performance / cross-platform behavior / state persistence
- Touches core path / unknown blast radius
Rule: If Repro=C or Clarity=C, include a discovery slice.
Workflow
1) Define Scope and Estimate Type
- Confirm what is in/out of scope
- Confirm estimate type: effort, calendar, cost, complexity
- Confirm confidence target(s): P50 / P80 (default), optionally P90
- Confirm constraints: deadlines, must-fix items, release boundary
2) Intake and Normalize the Backlog
- De-duplicate issues
- Merge near-duplicates and note uncertainty
- Group items by subsystem (auth, billing, UI, sync, infra)
- Identify unknown-unknown areas (legacy zones, flaky tests, poor observability)
3) Per-Item Breakdown
Estimate each item using this structure:
- Triage / reproduce
- Investigation / diagnosis (if needed)
- Implementation
- Tests (unit/integration/e2e as appropriate)
- Code review and iteration
- QA verification
- Release / deployment steps (if applicable)
Use hours only for work expected to be under one day; otherwise use engineer-days.
4) Dependencies and Sequencing
- Identify dependencies (internal modules, data migrations, external APIs, app-store releases)
- Mark blockers and parallelizable streams
- Flag sequencing needs (must land before X)
5) Risks, Unknowns, and Buffers
Maintain an Unknowns Register:
- Unknown → discovery task → decision/validation method → timebox
Risk buffer guidance:
- Low risk: +0–10%
- Medium risk: +10–25%
- High risk: +25–50%
- Unknown-heavy: include discovery and a re-estimate gate
6) Roll-Up Totals and Confidence
Produce:
- Per-item ranges (min/most-likely/max or P50/P80)
- Totals by bucket (must/should/nice)
- Overall confidence:
- P50: likely if things go normally
- P80: realistic commitment range
- P90: conservative range for high-stakes delivery
7) Validation and Re-Estimation Plan
Provide:
- Fastest validation steps to reduce uncertainty (logs, repro harness, spike)
- Re-estimation checkpoints (after discovery spikes, after first tranche)
Output Format (Required)
A) Executive Summary
- Scope statement (included/excluded)
- Estimate frame (effort vs calendar + capacity assumptions)
- Total estimates: P50 / P80 (and P90 if requested)
- Key risks and biggest unknowns
B) Backlog Estimate Table
For each item:
- ID / Title
- Bucket (Must/Should/Nice)
- Subsystem
- Triage scores (Repro/Clarity/Impact)
- Estimate (P50/P80)
- Risk flags
- Notes / assumptions
C) Totals by Bucket
- Must-fix total (P50/P80)
- Should-fix total (P50/P80)
- Nice-to-have total (P50/P80)
D) Assumptions and Exclusions
- Explicit assumptions (env access, test maturity, release cadence)
- Explicit exclusions (UX redesign, perf overhaul, refactors unless listed)
E) Risks and Unknowns Register
- Unknown → discovery plan → timebox → impact if true
F) Next Steps
- Top 3 actions to validate quickly
- Proposed sequencing / milestones
- Re-estimation trigger points
Common Mistakes
- Estimating a bug list as if it is already well-specified
- Skipping repro/triage and undercounting diagnosis time
- Ignoring testing, QA verification, and release overhead
- Mixing effort and calendar without a capacity model
- Overstating precision (single-number estimates with no confidence)
- Not separating must-fix from nice-to-have
Quick Reference
- Reference template: skills/development-estimation/references/estimate.md
- Preferred output: P50/P80 effort plus derived calendar via stated capacity
- Default unit: engineer-days (hours only for sub-day tasks)
Quality Bar
A good estimate is:
- Transparent about assumptions
- Broken down into components
- Risk-aware with explicit unknown handling
- Delivered as a range with confidence levels
- Paired with a plan to validate and tighten the range
Converted and distributed by TomeVault — claim your Tome and manage your conversions.
1---2name: development-estimation3description: Use when estimating time, effort, cost, or complexity for features, projects, refactors, and bug backlogs. Produces defensible estimates via triage, decomposition, risk handling, and confidence intervals, with clear assumptions and validation steps.4---56# Development Estimation78## Purpose910Create consistent, defensible estimates by:1112- Triaging and clarifying scope (especially for bug lists)13- Decomposing work into deliverable components14- Accounting for testing, QA, and release overhead15- Identifying risks and unknowns with explicit mitigation16- Producing confidence-based ranges (P50/P80/P90)1718Optimized for reviewing an existing project or backlog and producing a realistic delivery forecast.1920## When to Use2122- Estimating feature or project scope and delivery timelines23- Reviewing a backlog and producing a time estimate24- Producing risk-aware estimates with confidence intervals25- Converting a list of problems into an execution plan2627## Avoid When2829- The task is trivial and a gut-check is sufficient30- Requirements are unknown and discovery is the real work31- You lack access to the codebase or requirements3233## Inputs Required3435Provide as much as possible; estimate quality depends on clarity.3637### Minimum3839- List of items (bugs/features) with short descriptions40- Target platform/environment (e.g., iOS/Android/Web, staging/prod)41- Constraints (deadline, must-fix vs can-slip)4243### Helpful4445- Repro steps, logs, screenshots46- Architecture notes or codebase access47- Deployment pipeline and QA process48- Team capacity model (engineers, focus hours/day, meeting load)49- Definition of done (tests required, QA sign-off, release scope)5051## Estimation Frames5253Always confirm the estimate frame up front:5455- Effort: engineer-days or engineer-weeks56- Calendar: derived from capacity (effort / throughput)57- Cost: optional, requires rate assumptions58- Complexity: t-shirt sizing or points (only if requested)5960### Default Capacity Model6162Unless provided, assume:6364- 5–6 hours/day of effective build time per engineer65- Review and coordination overhead included per item66- QA/release overhead is stated explicitly as an assumption6768## Triage Rubric (Bug Backlog)6970For each bug, capture:7172### Repro7374- A: Always75- B: Sometimes / flaky76- C: Cannot repro / unclear7778### Clarity7980- A: Clear cause or clear fix path81- B: Partial (needs investigation)82- C: Unknown (needs discovery)8384### Impact8586- Blocker / High / Medium / Low8788### Fix Type8990- UI / Backend / Infra / Data / Dependency / Config / Unknown9192### Risk Flags9394- Concurrency / migrations / auth/security / payments / third-party API95- Performance / cross-platform behavior / state persistence96- Touches core path / unknown blast radius9798Rule: If Repro=C or Clarity=C, include a discovery slice.99100## Workflow101102### 1) Define Scope and Estimate Type103104- Confirm what is in/out of scope105- Confirm estimate type: effort, calendar, cost, complexity106- Confirm confidence target(s): P50 / P80 (default), optionally P90107- Confirm constraints: deadlines, must-fix items, release boundary108109### 2) Intake and Normalize the Backlog110111- De-duplicate issues112- Merge near-duplicates and note uncertainty113- Group items by subsystem (auth, billing, UI, sync, infra)114- Identify unknown-unknown areas (legacy zones, flaky tests, poor observability)115116### 3) Per-Item Breakdown117118Estimate each item using this structure:119120- Triage / reproduce121- Investigation / diagnosis (if needed)122- Implementation123- Tests (unit/integration/e2e as appropriate)124- Code review and iteration125- QA verification126- Release / deployment steps (if applicable)127128Use hours only for work expected to be under one day; otherwise use engineer-days.129130### 4) Dependencies and Sequencing131132- Identify dependencies (internal modules, data migrations, external APIs, app-store releases)133- Mark blockers and parallelizable streams134- Flag sequencing needs (must land before X)135136### 5) Risks, Unknowns, and Buffers137138Maintain an Unknowns Register:139140- Unknown → discovery task → decision/validation method → timebox141142Risk buffer guidance:143144- Low risk: +0–10%145- Medium risk: +10–25%146- High risk: +25–50%147- Unknown-heavy: include discovery and a re-estimate gate148149### 6) Roll-Up Totals and Confidence150151Produce:152153- Per-item ranges (min/most-likely/max or P50/P80)154- Totals by bucket (must/should/nice)155- Overall confidence:156 - P50: likely if things go normally157 - P80: realistic commitment range158 - P90: conservative range for high-stakes delivery159160### 7) Validation and Re-Estimation Plan161162Provide:163164- Fastest validation steps to reduce uncertainty (logs, repro harness, spike)165- Re-estimation checkpoints (after discovery spikes, after first tranche)166167## Output Format (Required)168169### A) Executive Summary170171- Scope statement (included/excluded)172- Estimate frame (effort vs calendar + capacity assumptions)173- Total estimates: P50 / P80 (and P90 if requested)174- Key risks and biggest unknowns175176### B) Backlog Estimate Table177178For each item:179180- ID / Title181- Bucket (Must/Should/Nice)182- Subsystem183- Triage scores (Repro/Clarity/Impact)184- Estimate (P50/P80)185- Risk flags186- Notes / assumptions187188### C) Totals by Bucket189190- Must-fix total (P50/P80)191- Should-fix total (P50/P80)192- Nice-to-have total (P50/P80)193194### D) Assumptions and Exclusions195196- Explicit assumptions (env access, test maturity, release cadence)197- Explicit exclusions (UX redesign, perf overhaul, refactors unless listed)198199### E) Risks and Unknowns Register200201- Unknown → discovery plan → timebox → impact if true202203### F) Next Steps204205- Top 3 actions to validate quickly206- Proposed sequencing / milestones207- Re-estimation trigger points208209## Common Mistakes210211- Estimating a bug list as if it is already well-specified212- Skipping repro/triage and undercounting diagnosis time213- Ignoring testing, QA verification, and release overhead214- Mixing effort and calendar without a capacity model215- Overstating precision (single-number estimates with no confidence)216- Not separating must-fix from nice-to-have217218## Quick Reference219220- Reference template: skills/development-estimation/references/estimate.md221- Preferred output: P50/P80 effort plus derived calendar via stated capacity222- Default unit: engineer-days (hours only for sub-day tasks)223224## Quality Bar225226A good estimate is:227228- Transparent about assumptions229- Broken down into components230- Risk-aware with explicit unknown handling231- Delivered as a range with confidence levels232- Paired with a plan to validate and tighten the range233234---235> Converted and distributed by [TomeVault](https://tomevault.io/claim/frumu-ai) — claim your Tome and manage your conversions.236<!-- tomevault:4.0:skill_md:2026-04-11 -->