estimation
Estimation
Estimate to expose uncertainty and trade-offs, not to pretend the future is certain.
Context
Estimation converts a task list into a planning signal the team can actually use. Good estimates make assumptions explicit, separate known work from uncertainty, and prevent schedules from quietly becoming fiction.
In Prodcraft, estimation follows task breakdown and should be informed by identified risks. The goal is calibrated planning, not false precision.
Inputs
- task-list -- The reviewed implementation slices to size.
- risk-register -- Known delivery, integration, and scope risks that should affect confidence or contingency.
Process
Step 1: Normalize the Unit of Estimation
Pick one estimation approach for the planning horizon: hours, ideal days, story points, or size buckets. Keep it consistent within the same plan.
Step 2: Estimate Task by Task
For each task, record:
- base size
- confidence level
- key assumptions
- blockers or external dependencies that could widen the range
If the estimate depends on an unresolved question, say so explicitly instead of guessing low.
Step 3: Calibrate Against Risk and History
Adjust estimates when risk, novelty, or coordination cost makes the base number misleading. Compare against similar recent work when available.
Step 4: Publish the Estimate Set
Package the estimates in a form sprint or milestone planning can consume directly. Distinguish between:
- confident work
- work with wide uncertainty
- work that should not be scheduled until a risk or dependency is resolved
Outputs
- estimate-set -- A structured set of estimates with confidence and assumptions for each planned task.
Quality Gate
- Every planned task has an estimate
- Confidence or uncertainty is explicit
- Key assumptions and blockers are recorded
- Risk materially changes estimates where appropriate
- The output is usable by downstream sprint or milestone planning
Anti-Patterns
- Single-number theater -- one precise number hiding wide uncertainty.
- Estimate equals commitment -- treating a planning signal as a promise.
- Ignoring coordination cost -- sizing coding work but not integration, review, or waiting time.
- Optimism by silence -- leaving assumptions unstated so the smallest number wins.
Related Skills
- task-breakdown -- provides the work items to size
- risk-assessment -- surfaces the uncertainties that affect confidence
- sprint-planning -- consumes the estimate set to choose realistic scope
- retrospective -- can compare actuals vs estimates for calibration
Distribution
- Public install surface:
skills/.curated - Canonical authoring source:
skills/03-planning/estimation/SKILL.md - This package is exported for
npx skills add/updatecompatibility. - Packaging stability:
beta - Capability readiness:
beta
More from yknothing/prodcraft
system-design
Use when reviewed requirements or specifications are ready and the team must decide high-level architecture, component boundaries, integration seams, or brownfield coexistence strategy before API design, technology selection, or task planning.
6ci-cd
Use when a reviewed implementation slice needs an automated build, test, and deployment pipeline, especially when brownfield rollback, release-boundary checks, contract/integration gates, and staged delivery must be explicit before shipping.
6intake
The mandatory gateway for all new engineering work. Triage and route new products, apps, features, migrations, tech-debt, or any 'not sure where to start' request to the correct lifecycle path. Use before starting design or implementation. Do not use for ongoing tasks, specific debugging, or PR reviews.
6feature-development
Use when a reviewed task slice has tests or acceptance targets and the team must turn it into a small, mergeable implementation increment without expanding scope, breaking contracts, or hiding release-boundary risk.
6monitoring-observability
Use when a live service or newly delivered release needs actionable telemetry, dashboards, and alerts that expose real user-impactful boundaries, especially when brownfield coexistence rules, unsupported-flow safety, rollback health, or queue/backfill behavior must be visible before incidents escalate.
6incident-response
Use when a live production issue needs coordinated containment, severity triage, stakeholder communication, and evidence capture, especially when a recent release, brownfield coexistence rules, rollback decisions, or unresolved contract boundaries must be handled before root-cause work.
6