Skip to content

Anti Patterns

Enreign edited this page Mar 8, 2026 · 3 revisions

Common estimation mistakes and how the skill guards against them.

The Seven Deadly Estimation Sins

1. Single-Point Estimates

The mistake: "This will take 4 hours."

Why it's harmful: Creates false certainty. Sets up failure — any deviation looks like a miss.

The guard: The skill always outputs ranges + PERT expected value + confidence bands. You can't get a single number without context.


2. Converting Story Points to Hours

The mistake: "1 point = 1 day, so 5 points = 5 days."

Why it's harmful: Defeats the purpose of relative sizing. Points measure complexity; hours measure time. They're different dimensions. Once converted, teams game the points to hit hour targets.

The guard: Story points are optional and come with an explicit warning: "Story points measure relative complexity, not time."


3. Estimating in Isolation

The mistake: Only the developer estimates. QA, ops, and PM don't participate.

Why it's harmful: Misses edge cases, deployment concerns, and requirement ambiguities that other roles would catch.

The guard: For L/XL tasks, the skill suggests team review. The detailed questionnaire surfaces integration, risk, and review concerns that force broader thinking.


4. Estimates as Commitments

The mistake: Treating the estimate as a deadline promise.

Why it's harmful: Teams pad defensively. Trust erodes when "estimates" are missed. Planning becomes adversarial.

The guard: The skill separates "expected" (what we think) from "committed" (what we promise) at explicit confidence levels. An expected value of 4 hours with a 90% committed value of 7.2 hours makes the uncertainty visible.


5. Velocity as a Performance Metric

The mistake: "Team A delivers 40 points per sprint, Team B only does 25. Team A is better."

Why it's harmful: Teams game velocity — inflating points, splitting tasks artificially, cutting quality. Cross-team comparisons are meaningless because point scales aren't calibrated.

The guard: The skill never presents velocity as productivity. It focuses on estimate accuracy (PRED(25)), not throughput.


6. Estimating Everything Upfront

The mistake: Pre-estimating the entire backlog with detailed hour breakdowns 6 months before the work starts.

Why it's harmful: Stories become outdated. The Cone of Uncertainty means early estimates are wildly inaccurate. Time spent estimating stale work is wasted.

The guard: Quick batch mode uses T-shirt sizing (S/M/L/XL) for rough backlog sizing. Detailed estimation is reserved for imminent work.


7. XL Tasks Without Decomposition

The mistake: Estimating "rewrite the backend" as a single XL task.

Why it's harmful: XL tasks have the widest uncertainty ranges and lowest agent effectiveness (30%). A single estimate for 2-6 weeks of work is barely more useful than a guess.

The guard: The skill triggers a warning: "XL estimates are directional only — the round-based model cannot capture emergent complexity at this scale. Break into L or smaller tasks before committing to deadlines." Agent effectiveness at XL (0.3) automatically inflates human time, making the cost of not decomposing visible. XL numbers should be treated as rough sizing, not commitments.


Additional Warnings the Skill Triggers

Pattern Warning
Total > 2 weeks "High uncertainty. Consider phased delivery with re-estimation."
Spread ratio > 3× "Wide range. Consider investigation spike first."
Definition = concept "Concept-phase. Estimates can be off by 2-4×."
Task = investigation "Timebox this. Output is a plan, not code."

Clone this wiki locally