Software estimation is famously hard because every task is a little novel. Teams reach for story points, planning poker, t-shirt sizes, or just throughput math — each works for a while, each fails differently. The healthy question isn't "how do we estimate perfectly?" but "what decision is the estimate informing?"
← Back to Methodologies & SDLC"As a <role>, I want <goal>, so that <benefit>."
A user story is a placeholder for a conversation, not a spec. The "so that" clause is the most-skipped and most-valuable part — it forces clarity on why.
INVEST heuristic: stories should be Independent, Negotiable, Valuable, Estimable, Small, Testable.
Acceptance criteria live alongside (often "Given / When / Then" — Gherkin format).
| Technique | Best for | Watch out for |
|---|---|---|
| Story points (Fibonacci 1, 2, 3, 5, 8, 13) | Relative effort within one team | Cross-team comparison; treating as time. |
| T-shirt sizes (XS / S / M / L / XL) | Coarse early-roadmap sizing | Becomes a sneaky points scale. |
| Hours / days | Tasks ≤ 1 day; ops work; contractors | False precision; padding wars. |
| #NoEstimates (count items) | Once item sizes are similar | Requires real story splitting discipline. |
| Monte Carlo on cycle time | Forecasting "when will N items be done?" | Needs ≥ 11 historical data points. |
The point isn't the number — it's the conversation that surfaces hidden complexity. If a senior says 3 and a newer dev says 13, you've found a gap in shared understanding before the work starts.