Pendahuluan

Secara natural, estimasi menggunakan perhitungan linear/aritmatika seperti 1,2,3,4,5 atau perhitungan geometri seperti 1,2,4,8,16 merupakan estimasi yang secara intuitive lebih mudah.

Percayalah.., mengatakan sesuatu tugas 4 kali lebih sulit dari sebuah tugas lain seharusnya lebih mudah, dibandingkan mengatakan sebuah tugas 1,6 kali lebih sulit dari tugas lainnya.

Tetapi ketika melakukan estimasi menggunakan story point dengan Fibonacci, maka kita akan dihadapkan dengan nilai Fibonacci seperti berikut :

½ , 1, 2, 3, 5, 8, 13, 20

Ketika kita dihadapkan pada estimasi sebuah task, misalkan sebuah story A diestimasi 3 story point. Tetapi ketika ada story lain misalnya story B yang secara analisa jelas lebih sulit dibandingkan story A, maka pilihan nya cuma story point 5 atau 8, dan tidak ada story point 6 atau 7.

Padahal mungkin saja kita merasa bahwa story B secara jelas 2 kali lipat lebih sulit daripada story A, sehingga nilai yang tepat adalah 6 story point.

Mau memilih 5 dirasakan terlalu optimistis, sementara memberi nilai 8 dirasakan terlalu pesimistis dan memberi bobot terlalu banyak terhadap story tersebut.

Hal ini cukup membingungkan dan membuat estimasi yang tidak logis dari sisi development.

Lalu kenapa penomoran Fibonacci yang tidak linear ini digunakan dalam story point ?

Sepertinya tidak ada alasan yang benar-benar cukup logis mengenai hal ini.

Secara umum, pemilihan tipe perhitungan story point memakai Fibonacci hanya salah satu dari banyak perhitungan estimasi selain dari T-Shirt, Bucket, Dot voting (silahkan baca Story Point - Pengenalan).

Hampir semua teknik estimasi tersebut bukanlah merupakan perhitungan linear. Dan itu secara filosofis mengisyaratkan bahwa estimasi di Agile bukanlah estimasi dngan cara eksak atau pasti, tapi relatif.

Sehingga kalau kita cari alasannya deret Fibonacci ini menjadi pilihan, maka alasan logisnya kemungkinan adalah :

  • untuk memasukkan unsur dinamis dalam estimasi untuk story yang tidak sederhana.

    Otak kita sebenarnya mudah untuk membandingkan 2 hal yang sederhana.

    4 deret pertama adalah point sederhana, yang merupakan kelipatan bulat dari angka sebelumnya. Kalau kita lihat story-story dengan nilai ½ , 1, 2, 3 biasanya adalah story sederhana yang dengan mudah kita kerjakan dan ketahui kerumitannya. Sederhana dalam hal ini juga adalah relatif tiap tim dan anggota tim.

    Dengan tingkat sederhana nya ini, maka dengan mudah kita akan melakukan pembobotan story point ½ , 1, 2, atau 3.

    Sementara story dengan story point 5, 8, dan selanjutnya adalah story tidak sederhana, ada komponen yang mungkin tidak kita ketahui detail, atau bisa saja kita ketahui nanti, atau bisa saja ada perubahan strategi untuk story tersebut, atau pengurangan dan penambahan scope. Hal ini merupakan sisi dinamis dari story-story yang tidak sederhana.

    Akan tetapi kita tidak punya cukup waktu untuk mengupas detail, dan mengetahui dari awal sisi dinamisnya, atau mengubah strategi nya agar story ini bisa selesai, sehingga yang diperlukan adalah estimasi kasar.

    Sehingga memilih 5 atau 8 untuk story adalah pilihan bersama tim. Kalau memang story pointnya lebih sulit dari story yang diboboti story point 3, maka dengan story point 5, maka story tersebut mesti selesai dengan scope yang lebih kecil ketika ternyata realnya adalah story point 6.

    Tetapi kalau diboboti dengan 8, maka mungkin ada perbaikan dan penambahan kualitas dari pekerjaannya karena misalnya ternyata realnya adalah story point 6.

  • Pemilihan story point juga akan membuat abstraksi dalam mental mindset mengenai bagaimana seharusnya sebuah story diselesaikan.

    Kembali contoh diatas, ketika ternyata realnya di implementasinya adalah story point 6, maka dengan story point 8, ada mindset dan dinamika story bahwa story tersebut disempurnakan dengan penambahan kualitas atau scope.

    Begitu pula ketika realnya story point 6, dan ternyata di awal diestimasi dengan 5, maka mungkin akan ada dinamika tim untuk pengurangan scope dan kualitas dalam pengerjaan storynya.

  • memaksa Product Owner untuk membuat story dalam bentuk yang cukup kecil agar mudah diestimasi, dideliver dengan tingkat keakuratan estimasi yang memadai.

    Pembobotan story point ini juga berguna untuk melatih Product Owner dan tim untuk membuat story yang INVEST (Independent, Negotiable, Valuable, Estimable, Small, Testable).

    Ketidak sesuaian estimasi untuk story dengan story point tinggi akan membuat ketidak konsistenan antara sprint, dan akhirnya membuat tim perlu mengevaluasi story agar lebih akurat dengan kapasitas tim.

  • mempercepat estimasi untuk story dengan tingkatan kerumitan tinggi.

    Story dengan tingkat kerumitan tinggi membutuhkan analisa yang tajam dan lengkap agar bisa diestimasi. Banyak komponen yang mesti dilihat, resiko yang tidak kita sadari, atau multiplikasi kerumitan ketika ada hambatan yang dihadapi nantinya waktu implementasi.

    Menghabiskan waktu untuk akurat terhadap story jenis ini membuang waktu. Cukup estimasi dengan pola estimasi optimis atau pesimis, lalu implementasikanlah. Kalau optimis misalnya story point menjadi 5, kalau pesimis, maka story point menjadi 8. Kalau ternyata tidak sesuai estimasi kita tersebut di dalam pelaksanaan, maka kualitas dan scopenya bisa diubah, atau ditambahkan atau dikurangi dengan story yang lain.

    Ketidak akuratan ini bisa menjadi input di dalam sprint retro dan menginisiasi pembuatan story yang lebih kecil dan mudah diestimasi sesuai dengan kapasitas tim. Yang penting tim bisa bekerja untuk menyelesaikan tugasnya dan goalnya di sprint tersebut.