Estimation Patterns (Meta-Skill)

Systematic approaches for producing accurate, defensible software estimates.

Installation

OpenClaw / Moltbot / Clawbot

npx clawhub@latest install estimation-patterns

When to Use

• Estimating a feature, bug fix, or project timeline
• Breaking down work for sprint planning or roadmap forecasting
• Presenting estimates to stakeholders or product managers
• Reviewing historical accuracy to calibrate future estimates
• Noticing a pattern of missed deadlines or blown budgets

Estimation Methods

Choose the method that matches your context and audience.

Three-point formula (PERT):

Expected = (Optimistic + 4 x Likely + Pessimistic) / 6
Standard Deviation = (Pessimistic - Optimistic) / 6

Use the standard deviation to express confidence ranges (e.g., "3-5 days at 68% confidence, 2-6 days at 95%").

Task Decomposition

Break work down until every sub-task is < 4 hours of effort. Anything larger hides unknowns.

Decomposition checklist:

1. Can I describe what "done" looks like in one sentence?
2. Is there exactly one unknown, or zero?
3. Could a teammate pick this up without a walkthrough?
4. Is it under 4 hours? If no — split again.

If you cannot decompose a task, it signals a spike is needed. Timebox the spike (2-4 hours), then re-estimate.

Complexity Multipliers

Apply these multipliers to your base estimate when complexity factors are present. Multipliers stack multiplicatively.

Example: A 2-day base estimate on legacy code (1.5x) with unclear requirements (2.0x) becomes 2 x 1.5 x 2.0 = 6 days.

Rule: Never apply more than 3 multipliers — if that many factors converge, the task needs a spike or a scope reduction, not a bigger number.

Buffer Calculation

Raw estimates are point predictions. Reality is a distribution.

Effective estimate formula:

Effective = (Base Estimate x Multipliers) / Focus Ratio + Buffer

Focus ratio guidelines:

Historical Calibration

Track actual vs estimated to improve over time. This is the single most effective way to get better at estimation.

Tracking table:

Accuracy ratio: Calculate your rolling average of Actual / Estimated over the last 10-20 tasks.

• Ratio < 0.8 — you're overestimating (sandbagging or excessive buffers)
• Ratio 0.8-1.2 — well calibrated
• Ratio > 1.2 — you're underestimating (apply the ratio as a correction factor)

Calibration action: Multiply future estimates by your rolling accuracy ratio until it converges toward 1.0.

Common Estimation Biases

Recognize these cognitive traps — awareness alone reduces their effect.

Estimation by Task Type

Use these ranges as starting heuristics, then adjust with multipliers and historical data.

Communication

How you present an estimate matters as much as the number itself.

Always present as a range, never a single number:

• Bad: "It'll take 5 days."
• Good: "3-7 days, most likely 5. The range depends on the payment API response format — I'll know more after the spike."

Confidence levels:

Stakeholder communication rules:

1. State the range and the confidence level together
2. Name the top 1-3 risks that could push toward the upper bound
3. Offer to de-risk with a timeboxed spike before committing
4. Explicitly state what is not included (e.g., "does not include QA, deployment, or docs")
5. Update estimates proactively when new information surfaces — don't wait until the deadline

Anti-Patterns

NEVER Do

1. NEVER give a single-number estimate without a range — it communicates false precision and sets you up for failure
2. NEVER estimate a task you haven't decomposed — large estimates are guesses wearing a suit
3. NEVER let an old estimate stand after scope changes — estimates are invalidated the moment requirements shift
4. NEVER estimate in someone else's units — your days are not their days; clarify assumptions about focus time and interrupts
5. NEVER skip recording actuals — estimation without feedback is astrology, not engineering
6. NEVER commit to an estimate made under pressure — say "let me break this down and get back to you in an hour"
7. NEVER treat an estimate as a promise or a deadline — estimates are probabilistic forecasts, not contracts