Kenapa Estimasi Software Selalu Salah — dan Cara Bikinnya Tidak Lebih Buruk

Estimasi bukan ramalan. Estimasi itu taruhan berisi informasi. Selama diperlakukan sebagai janji, dia akan selalu "salah".

Kenapa meleset (bukan karena tim bodoh)

Tiga penyebab struktural, bukan personal:

1. Planning fallacy — Kahneman & Tversky. Otak manusia mengestimasi pakai best case scenario, bukan distribusi kejadian masa lalu. Kamu membayangkan jalan mulus, bukan 3 hari debugging env yang rusak.

2. Pekerjaan yang tidak kelihatan — kode yang kamu tulis cuma ~30-40% dari waktu. Sisanya: baca kode lama, meeting, nunggu review, fix CI, nulis test, deploy gagal, balik lagi. Yang diestimasi cuma puncak gunung es.

3. Ketidakpastian mengecil, bukan konstan — Steve McConnell sebut ini Cone of Uncertainty. Di awal proyek, rentang error bisa 4x lebih besar dari perkiraan. Di akhir proyek baru menyempit. Artinya: estimasi di minggu pertama proyek secara matematis tidak bisa akurat. Bukan salah orangnya.

Hofstadter's Law menambahkan bumbu: "It always takes longer than you expect, even when you take into account Hofstadter's Law."

Realita lapangan

Story point ≠ jam. Begitu PO bertanya "1 point berapa jam?", sistemnya sudah rusak. Point mengukur relative size, bukan durasi. Kalau dipaksa jadi konversi, tim akan main aman — inflate semua estimasi, velocity jadi angka politik, bukan sinyal.

Velocity dipakai sebagai target → rusak. Kalau manajemen bilang "velocity bulan ini harus 60", tim akan (a) pecah tiket jadi lebih kecil biar kelihatan banyak, atau (b) skip test biar cepat. Keduanya menghancurkan justru metrik yang mau diukur. Goodhart's Law: when a measure becomes a target, it ceases to be a good measure.

Estimasi jadi komitmen tanggal → tekanan → kualitas korban. Ini anti-pattern paling mahal. Tim yang ditekan biasanya tidak deliver lebih cepat; mereka deliver lebih cepat sampai bug pertama, lalu biayanya muncul 3 bulan kemudian sebagai technical debt.

Yang benar-benar membantu

Reference class forecasting. Jangan mulai dari nol. Tanya: "fitur serupa terakhir butuh berapa lama?" Pakai data historis sebagai basis, bukan perasaan. Flyvbjerg pakai ini untuk proyek infrastruktur besar; untuk tim kecil pun jalan — cek 5 tiket mirip terakhir, ambil median, bukan rata-rata (outlier merusak rata-rata).

Beri rentang, bukan angka tunggal. "3-6 hari" jujur. "4 hari" palsu — presisinya tidak ada di baliknya. Kalau stakeholder butuh satu angka, kasih angka atas rentang itu dan bilang itu P80, bukan P50.

Pecah kerja hanya sedalam yang kamu paham. Kalau tiket masih "bikin modul pembayaran", estimasinya fiksi. Batas praktis: tiket yang bisa selesai dalam 1-2 hari. Di bawah itu, overhead tracking lebih besar dari manfaatnya.

Ukur cycle time, bukan cuma velocity. Cycle time = dari tiket mulai dikerjakan sampai selesai. Ini mengukur aliran nyata dan tidak bisa digaming semudah velocity. Kalau cycle time naik sementara velocity stabil, ada yang nyangkut di review atau QA.

Spike untuk yang benar-benar gelap. Kalau tidak tahu sama sekali, jangan estimasi — jadwalkan 1-2 hari investigasi, lalu estimasi. Menebak di atas ketidaktahuan bukan estimasi, itu undian.

Checklist kecil untuk sprint planning

• [ ] Tiap tiket punya definisi "selesai" yang jelas (bukan cuma "kode jalan")
• [ ] Estimasi pakai rentang atau pakai data historis tiket mirip
• [ ] Masukkan buffer untuk review, test, deploy — bukan cuma coding
• [ ] Kalau ada yang tidak tahu, tulis "unknown", jangan dikasih angka asal
• [ ] Velocity dilihat sebagai tren 3 sprint, bukan angka sprint ini
• [ ] Tidak ada yang mengubah point jadi jam di depan tim

Satu hal yang bisa langsung dipakai

Buka tiket terakhir yang selesai di repo/board kamu. Hitung: berapa hari dari in progress sampai done, versus berapa yang kamu estimasi di awal. Selisihnya — itu faktor koreksi pribadi kamu. Pakai faktor itu untuk estimasi berikutnya, bukan feeling. Kebanyakan orang menemukan faktor 1.5-2.5x, dan angka itu lebih berguna dari semua teori.

Takeaway

Estimasi yang jujur adalah rentang dengan asumsi tertulis. Estimasi yang jadi tanggal mati adalah janji yang ditulis orang lain pakai tanganmu — dan yang kena getahnya tetap kamu.