Estimation

Useful estimates communicate uncertainty, dependencies, integration risk, review and test effort, and what would change the forecast—not a single optimistic coding hour total. Treat estimates as planning tools for slicing and de-risking.

| Factor | Why it affects the estimate | |--------|----------------------------| | Unknown APIs | Spikes or contracts needed first | | Data migration | Backfill, dual-write, rollback | | Cross-team deps | Waiting, alignment meetings | | Test surface | E2E, load, security review | | Operational work | Flags, dashboards, runbooks |

					Range: 3–5 days (60% confidence)
Assumptions: schema frozen, design approved
Spike: 0.5d on export queue limits
Would increase if: new auth provider required
				

On interviews: give a range, list assumptions, propose a spike for the riskiest unknown, and describe the first thin slice that validates the approach.

Common pitfalls: single-date promises; ignoring review and QA; estimates without dependencies; treating estimates as commitments.

The trade-off is stakeholder desire for certainty versus honest ranges that enable replanning.

Checklist:

• State range and confidence, not one number.
• Name dependencies and integration risk.
• Include validation and operational work.
• Identify spikes that reduce unknowns.