Mengapa Estimasi Gagal (dan Mengapa Tetap Diperlukan)

• Dalam pengembangan perangkat lunak, estimasi pekerjaan berada di ranah Complex, dan bahkan tim yang sangat berpengalaman pun pada dasarnya tidak bisa membuat estimasi yang benar-benar akurat
• Gerakan #NoEstimates merupakan reaksi yang sah terhadap kenyataan bahwa estimasi disalahgunakan sebagai target kinerja, tetapi menolak estimasi itu sendiri membuat organisasi kehilangan kemampuan untuk berkoordinasi
• Nilai utama estimasi bukanlah memprediksi masa depan, melainkan komunikasi dan koordinasi di bawah ketidakpastian, dan hal ini penting untuk kontrak eksternal, dependensi antartim, dan penilaian ROI
• Menurut Cone of Uncertainty dari Steve McConnell, pada tahap awal proyek kesalahan estimasi bisa mencapai 4x lipat, dan rentangnya hanya menyempit melalui pembelajaran
• Organisasi perlu mengubah kebiasaan yang menjadikan estimasi sebagai komitmen, dan mengadopsi pendekatan estimasi yang berbasis rentang, menyatakan asumsi secara eksplisit, dan dikalibrasi secara bertahap

---

Masalah yang Benar-Benar Diselesaikan oleh Gerakan #NoEstimates

• Pola yang sama terus berulang: tim diminta membuat estimasi ketika mereka hampir belum tahu apa-apa tentang masalahnya, lalu angka itu dimasukkan ke roadmap dan dijanjikan kepada pelanggan
• Ketika kenyataan berbeda dari estimasi, tim dituduh "melewatkan deadline", padahal itu bukan deadline yang sejak awal mereka setujui
• Patologi utamanya adalah ketika estimasi berubah dari prediksi menjadi komitmen
• Solusi "jangan melakukan estimasi" ibarat merespons termometer yang rusak dengan menyangkal konsep suhu itu sendiri
• Seperti ungkapan Maarten Dalmijn, estimasi tidak mengubah jumlah pekerjaan yang nyata; pengembangan fitur memerlukan waktu selama yang memang diperlukan
  • Yang dipengaruhi estimasi bukan pekerjaannya, melainkan ekspektasi di sekitarnya
  • Mengelola ekspektasi secara jujur dan jelas adalah pekerjaan yang sangat layak dilakukan

Mengapa Organisasi Benar-Benar Membutuhkan Estimasi

• Hal yang hampir selalu hilang dalam diskusi #NoEstimates: estimasi bukan untuk tim yang mengerjakan tugas, melainkan untuk organisasi di sekitarnya

• Ada tiga situasi ketika estimasi tak terhindarkan

• Komitmen eksternal (External commitments): kontrak pelanggan, rilis yang terikat kampanye pemasaran, deadline regulasi, dan sejenisnya membutuhkan model durasi pekerjaan untuk menilai kelayakan

  • "Kami tidak melakukan estimasi" bukan jawaban yang bisa diberikan kepada pelanggan, dan bisa berujung pada berakhirnya kontrak

• Dependensi antartim (Inter-team dependencies): ketika tim B harus menunggu tim A selesai, jika tim A tidak memberi prediksi apa pun maka tim B tidak bisa merencanakan

  • Sinyal kasar seperti ("mungkin 6 minggu, maksimal 8 minggu") jauh lebih berguna daripada diam, dan ini bukan soal kontrol melainkan bentuk penghormatan kepada anggota tim di hilir

• Perhitungan ROI: untuk memutuskan apakah akan membangun fitur X atau fitur Y, dibutuhkan model biaya relatif

  • Jika semuanya dianggap tak bisa diketahui, trade-off rasional menjadi mustahil; dan jika tetap harus menebak, maka tebakan terstruktur dengan asumsi yang dinyatakan jelas lebih baik

Joseph Pelrine Menunjukkan Kesulitan Hakiki dalam Estimasi

• Joseph Pelrine adalah Certified Scrum Trainer pertama di Eropa, yang meneliti agile software melalui lensa ilmu kompleksitas sosial
• Ia melakukan eksperimen terhadap lebih dari 300 orang yang bekerja dalam pengembangan perangkat lunak agile dengan menempatkan aktivitas kerja harian mereka ke dalam domain framework Cynefin (model sensemaking dari Dave Snowden)
  • Cynefin mengelompokkan masalah ke dalam empat domain: Clear, Complicated, Complex, dan Chaotic
• Estimasi pekerjaan secara konsisten dan berulang ditempatkan di domain Complex
• Perbedaan antara Complicated dan Complex adalah kuncinya:
  • Dalam domain Complicated, hubungan sebab-akibat bisa dipahami, dapat dilacak oleh ahli, dan keahlian dapat menghasilkan prediksi yang andal
  • Dalam domain Complex, hubungan sebab-akibat hanya bisa dipahami setelah kejadian, karena sistemnya terlalu saling terkait, bergantung pada konteks, dan sensitif terhadap perubahan kecil
• Inilah alasan pengembangan perangkat lunak bukan manufaktur: hampir selalu membangun sesuatu yang belum pernah ada sebelumnya di atas codebase yang unik dengan dinamika tim yang unik
  • Analogi tukang kayu tidak bekerja karena lemari kurang lebih mirip dengan lemari lain, tetapi fitur tidak kurang lebih mirip dengan fitur lain
• Bahkan tim yang hebat pun hanya mampu menghasilkan estimasi pada tingkat biasa-biasa saja, bukan karena kurang terampil, tetapi karena ada batas bawaan terhadap akurasi di domain Complex
• Tujuannya bukan membuat estimasi yang tepat, melainkan membuat keputusan yang berguna meskipun ada ketidakakuratan yang melekat

Apa yang Dikatakan Cone of Uncertainty

• Konsep Cone of Uncertainty dari Steve McConnell: pada awal proyek, kesalahan estimasi bisa mencapai 4x ke dua arah (total rentang 16x)
• Seiring proyek berjalan dan elemen yang belum diketahui terselesaikan — seperti klarifikasi requirement, penetapan arsitektur, dan penemuan serta penyelesaian masalah sulit — kerucut ini menyempit
• Ironinya: momen ketika estimasi paling akurat adalah tepat sebelum selesai, yaitu saat estimasi justru paling tidak dibutuhkan
  • Pada tahap awal, ketika estimasi paling berguna (saat arah masih bisa diubah atau proyek bisa dihentikan), justru informasi yang diketahui paling sedikit
  • Sebagian besar organisasi justru membuat komitmen paling tegas tepat pada tahap awal itu
• Ada dua implikasi tambahan:
  • Kerucut ini menunjukkan kasus terbaik untuk estimator yang terampil, dan kebanyakan tim performanya lebih buruk dari itu
  • Menetapkan tanggal pasti pada tahap konsep awal bukanlah perencanaan, melainkan membuat harapan lalu menyusun jadwal sesuai harapan itu
  • Kerucut hanya menyempit lewat keputusan yang menghilangkan ketidakpastian, bukan lewat berlalunya waktu
  • Mendefinisikan scope, menyelesaikan hal-hal arsitektural yang belum diketahui, menulis kode nyata, dan menemukan titik sulit akan menyempitkan kerucut; hanya mengadakan rapat selama 3 minggu tidak akan menyempitkannya
• Kepada stakeholder, perlu disampaikan secara eksplisit bahwa "kualitas estimasi bergantung pada posisi kita di dalam kerucut"
  • Pada minggu pertama, Anda tidak bisa memberi angka setara pekerjaan 2 minggu, tetapi Anda bisa memberi rentang dan menjelaskan apa yang perlu dipastikan agar rentang itu menyempit
  • Sebagian besar stakeholder dapat menerima penjelasan tentang kerucut ini; hanya saja tidak ada yang pernah memberi tahu mereka bahwa meminta rentang itu boleh

Mengapa Menggunakan Skala Fibonacci

• Nonlinearitas skala Fibonacci (1, 2, 3, 5, 8, 13, 21) menjalankan fungsi epistemik
• Selisih antara 2 dan 3 hanya menunjukkan "perbedaan kasar", tetapi lompatan dari 8 ke 13 mengodekan bahwa pita ketidakpastian lebih lebar daripada nilai estimasinya sendiri
  • Story 13 poin bukan berarti "tepat 13", melainkan "jelas lebih tidak pasti daripada 8, tapi belum sampai kategori 21"
• Jarak antarangka Fibonacci mencerminkan cara kompleksitas benar-benar berkembang
  • Hal kecil masih bisa diperkirakan secara kasar, tetapi hal besar mengandung lebih banyak unknown, titik integrasi, dan kejadian tak terduga, sehingga jauh lebih sulit diprediksi secara eksponensial
  • Story bernilai 21 (atau 13) ke atas berarti "kita belum memahami pekerjaannya, jadi harus dipecah"
• Fungsi lain dari estimasi Fibonacci yang sering diremehkan adalah apa yang terjadi selama percakapan estimasi
  • Jika satu orang mengatakan 3 dan orang lain mengatakan 13, angkanya sendiri hampir tidak penting; yang penting adalah mengapa tim yang sama melihat story yang sama dengan cara yang begitu berbeda
  • Bisa jadi salah satu pihak menemukan dependensi, atau mengetahui batasan teknis yang tidak tertulis di tiket
• Nilai terbesar dari estimasi bukan angkanya, melainkan memastikan apakah pemahaman bersama sudah terbentuk
  • Jika mekanisme pemaksa ini dihapus, pemahaman bersama sering kali baru terbentuk ketika seseorang menemui kompleksitas tersembunyi pada hari ketiga pengerjaan
• Inilah alasan sulit menyetujui klaim #NoEstimates bahwa "rapat estimasi itu pemborosan": jika dijalankan dengan baik, percakapan itu justru menghasilkan alignment
  • Jawaban untuk rapat yang buruk bukanlah membatalkan rapat

Jebakan Komitmen dan Cara Menghindarinya

• Disfungsi terdalam yang ditanggapi gerakan #NoEstimates adalah: estimasi diubah menjadi komitmen lewat tekanan sosial, bukan lewat logika
• Salah satu mode kegagalan terkait: orang yang tidak mengerjakan tugas membuat timeline dan melemparkannya ke tim, sehingga tercipta kombinasi terburuk antara estimasi yang tidak akurat + tim yang tidak merasa memiliki angka itu
  • Ketika realitas meleset, tidak jelas siapa yang bertanggung jawab sehingga semua orang saling menyalahkan
  • Orang yang menjalankan pekerjaan harus selalu memiliki estimasinya; memaksakan estimasi dari luar bukan optimisme, melainkan tanda awal permainan saling menyalahkan
• Ketika obsesi terhadap deadline mengakar, semua percakapan menyempit menjadi "bagaimana cara memenuhi deadline?", dan pertanyaan apakah kita sedang membangun hal yang benar menghilang dari pandangan
• Tiga hal yang sering dicampuradukkan organisasi harus dipisahkan:
  1. Estimasi (Estimate): prediksi probabilistik pada tingkat ketidakpastian saat ini, yang harus disertai pernyataan eksplisit tentang rentang dan asumsi
     • Contoh: "Kami memperkirakan 4–6 minggu, dengan asumsi tidak ada perubahan requirement dan pertanyaan API dijawab sebelum Jumat depan"
  2. Rencana (Plan): komitmen terhadap proses, bukan hasil
     • Contoh: "Kami akan bekerja selama 2 minggu, lalu meninjau progres dan memberi prediksi yang diperbarui"
  3. Komitmen (Commitment): janji terhadap hasil, yang seharusnya jarang dibuat dan hanya ketika kerucut sudah cukup menyempit
     • Komitmen pada tahap konsep awal bukan keberanian, melainkan kecerobohan
     • Saat dipaksa membuat komitmen, cobalah membuat komitmen pada prioritas, bukan timeline; jika itu pun tidak bisa, sertakan tingkat keyakinan sebagai bagian dari komitmen
• Praktik organisasi yang memperlakukan estimasi sebagai komitmen begitu angka itu diucapkan adalah sumber utama disfungsi
  • Solusi politis #NoEstimates (tidak menyebut angka sama sekali) dapat dipahami, tetapi biayanya adalah organisasi kehilangan kemampuan mengalokasikan sumber daya, mengurutkan dependensi, dan berbicara jujur dengan stakeholder eksternal
• Solusi yang lebih baik adalah mengajarkan kerucut, mendidik stakeholder, dan setiap kali memberi angka selalu menjelaskan perbedaan antara estimasi dan komitmen
  • Ini lebih sulit dan memakan waktu lebih lama daripada menolak estimasi, tetapi alih-alih menghindari situasi yang bisa merusak kepercayaan, pendekatan ini justru membangun kepercayaan

Praktik Estimasi yang Baik

• Lakukan estimasi lebih belakangan: kerucut hanya menyempit lewat pembelajaran, jadi lakukan spike, tulis kode eksploratif, dan ajak bicara tim yang akan terlibat integrasi terlebih dahulu
  • Tekanan untuk memberi angka sebelum pembelajaran yang membuat angka itu bermakna harus dilawan
• Jangan berlebihan memecah pekerjaan sebelum mulai: ketika menghadapi ketidakpastian, orang cenderung ingin membagi pekerjaan menjadi bagian yang lebih kecil, tetapi dekomposisi yang berlebihan tidak otomatis menghasilkan estimasi yang andal
  • Perencanaan awal yang terlalu rinci akan menjadi kaku, membuat tim tetap berpegang pada rencana bahkan ketika rencana itu tak lagi mencerminkan realitas, dan pada akhirnya membuat kesenjangan terasa lebih membingungkan
  • Mulailah dengan rencana sederhana yang mudah disesuaikan
• Berikan rentang, bukan estimasi titik: "3–5 minggu" lebih jujur daripada "4 minggu" tetapi hampir sama bergunanya untuk dieksekusi
  • Jika hanya satu angka yang diizinkan, berikan nilai tengah dari rentang itu, sambil menjelaskan bahwa itu adalah nilai tengah
  • Sepakati penggunaan Cone of Uncertainty dengan stakeholder dan rujuk padanya setiap kali menyampaikan estimasi
• Buat asumsi menjadi terlihat: kualitas estimasi hanya sebaik asumsi yang mendasarinya, jadi nyatakan secara eksplisit asumsi seperti tidak ada perubahan scope, pendekatan teknis tertentu yang dipakai, atau pengiriman dari tim lain pada tanggal tertentu
  • Asumsi yang hanya ada di kepala akan berubah menjadi kesalahpahaman pada saat terburuk
• Lacak akurasi, tetapi jangan menghukum: tujuannya untuk kalibrasi, bukan menyalahkan
  • Tim yang mengestimasi bersama selama 6 bulan dan meninjau akurasinya akan mengembangkan intuisi bersama tentang di mana mereka secara sistematis melebihkan atau meremehkan estimasi
  • Jika estimasi yang meleset dihukum, tim akan defensif dan menggelembungkan angka; estimasi yang dibengkakkan lebih tidak berguna daripada estimasi yang jujur namun tidak pasti
  • Estimasi yang salah di domain Complex bukan cacat karakter, melainkan sifat domain itu sendiri
• Di atas 8 harus dipecah: story Fibonacci bernilai 13 atau 21 hampir selalu menyimpan kompleksitas tersembunyi yang belum muncul ke permukaan
  • Tindakan memecah story memaksa tim menyatakan dengan jelas apa yang sebenarnya sudah diketahui
  • Sering kali ditemukan bahwa dari 3 substory, 2 di antaranya kecil, dan seluruh ketidakpastian terkonsentrasi pada 1 substory

Kebenaran yang Tidak Nyaman bagi Kedua Kubu

• Estimasi bukan kalkulasi, melainkan bentuk komunikasi, dan tujuannya bukan meramal masa depan, melainkan mendukung koordinasi dan pengambilan keputusan di bawah ketidakpastian
• Mode kegagalan estimasi bukan acak, melainkan sistematis: estimasi terlalu dini, memperlakukan rentang sebagai titik, memperlakukan estimasi sebagai komitmen, mengabaikan posisi epistemik dalam Cone of Uncertainty, dan memaksakan estimasi kepada pelaksana
• Yang disebut Dalmijn sebagai Complex Work Estimation Fallacy: keyakinan bahwa jika kita lebih sering mengestimasi, memperbaiki proses, dan bekerja bersama lebih lama, maka pada akhirnya estimasi akan menjadi akurat
  • Di domain Complex, batas akurasi estimasi bukan fungsi dari kedewasaan tim, melainkan fungsi dari domain itu sendiri
  • Kita bisa menjadi lebih baik, tetapi tidak menjadi tepat; mencampuradukkan keduanya membuat organisasi menghukum tim atas sesuatu yang secara hakiki berada di luar kendali mereka
• Menolak estimasi hanyalah keluar dari permainan koordinasi
  • Itu mungkin dilakukan untuk tim yang benar-benar independen, continuous deployment, dan tanpa komitmen eksternal, tetapi kebanyakan orang tidak bekerja dalam konteks seperti itu sepanjang kariernya
• Pilihannya bukan "estimasi buruk" vs "tanpa estimasi", melainkan estimasi implisit dan berkualitas rendah (yang akan tetap dibuat organisasi tanpa Anda) vs estimasi eksplisit yang rendah hati, berbasis rentang, dan memperlihatkan asumsi
• Karena estimasi pekerjaan berada di domain Complex, pendekatannya harus memakai mindset kompleksitas: eksplorasi, observasi, respons, estimasi, pelacakan, dan kalibrasi secara berulang
• Kerucut tidak menyempit karena menunggu, melainkan karena belajar