The Math behind Project Scheduling, Bug Tracking, and Triage
summary
Presents concrete rules and simulations that actually predict schedules: an ad‑hoc simulator SimSWE models spikes when features change late, showing a team of ~10 developers finishes slower the more features are parallelized. Recommends relative estimates like story points (not days), burn‑down/up charts to forecast launches, Kanban to reduce multitasking, and triage practices (labels, rolling queries) to avoid dramatic resets called bug bankruptcy. Shows real data: ~1,300 bugs over ~5.5 years and 60,000 tickets over 6.5 years to prove the math.
AI-written summary · about
chapters (13)
- 0:00Start
- 3:39Student Syndrome
- 11:07Story points are ratios
- 13:31What is a story anyway?
- 15:28Strict prioritization
- 20:26How to do project planning
- 21:43Restricted multitasking (Kanban)
- 25:20Stories are not bugs
- 26:55Every bug is, on average, the same size
- 33:32Bug scheduling tips
- 35:10Bug bankruptcy doesn't work (ingress egress)
- 38:31Bug tracking: You're holding it wrong
- 43:20Questions
related talks
46mEstimates and complexity: a tale in 42 and a half minutes
44mAgile metrics for predicting the future
43mPredictable Delivery
30mSoftware Estimation Made Easy
47mAccounting for Agile software
42mEstimates: Is There a Silver Bullet?
07mEstimates are BS
20mHow long is a piece of string? Solving the conundrum of software estimation