How to not shoot yourself in the foot with estimation
summary
Claims concrete: become empirically predictable by delivering every two weeks, measure throughput and cycle time, and forecast with a burn‑up cone (aka yesterday's weather) instead of guessing. Practises: keep a single ordered backlog, run a steady cadence of plan/review/release, call out assumptions, show confidence levels, and use data to steer. Example tradeoffs: a full integration may be 6–8 weeks while a manual approach is 2–3 days—so estimate options not solutions and never promise a precise delivery date.
AI-written summary · about
chapters (22)
- 0:00Intro
- 1:45Shoot yourself in the foot
- 3:45Scrum
- 4:50Does feedback make us unpredictable
- 5:35deterministic vs empirical predictability
- 7:40reducible uncertainty
- 8:06predictability
- 10:36transparency
- 14:15estimation
- 16:08different departments
- 17:17precision
- 17:39calling out
- 20:11never give a precise date
- 23:18prioritization
- 26:46estimating
- 27:54controlling time
- 28:46estimating options
- 30:34revisiting estimates
- 31:38metrics for delivering
- 33:59use data
- 35:16Inverted backlog
- 42:53Summary
related talks
47mCreating efficient, accurate, software estimations
48mNoEstimates
29mSoftware estimation – embracing nuance and controlled chaos
45mBeyond Estimates
16mPractically predictable – Forecasting delivery when nothing is certai
58mThe State of NoEstimates
42mEstimates: Is There a Silver Bullet?
43mPredictable Delivery