Story Point Itu Tidak Bermakna, Ukurlah Queue

• Story point sepenuhnya tidak dapat diandalkan dan menimbulkan kebingungan, sehingga artinya harus terus-menerus diingatkan kepada para pemangku kepentingan
  • Nilai poin yang rendah memang lebih akurat, tetapi nilai poin yang tinggi mengasumsikan volatilitas yang tinggi dan merepresentasikan rentang, sehingga tidak bisa dijumlahkan secara akurat
  • Story point tidak merepresentasikan waktu, tetapi ketika digabungkan dengan metrik velocity, pada praktiknya menjadi berarti waktu, sehingga sejak awal merusak tindakan menjumlahkan angka dan rentang
• Estimasi perangkat lunak itu sulit, dan output dari prosesnya umumnya tidak sebanding manfaatnya dibanding input yang dikeluarkan
• Tim kecil dengan sedikit gangguan tampak seperti mampu mengestimasi secara akurat, sehingga dalam banyak kasus memberi kesan bahwa apa yang mereka lakukan berjalan baik
• Ketika capacity dimanfaatkan sepenuhnya, volatilitas semua pekerjaan meningkat tajam, sehingga berdampak besar pada semua estimasi dan timeline
• Queue yang diukur menyelesaikan masalah estimasi jangka pendek dan jangka panjang, secara alami menangani perubahan cakupan, serta memberi praktik yang jauh lebih bernilai bagi tim besar dengan menghilangkan ketidakpastian
• Queue yang diukur memberikan indikator utama yang memprediksi masalah 20 kali lebih cepat daripada metrik terkait velocity atau cycle time

Apa itu story point?

• Menurut Atlassian, story point adalah satuan untuk mengekspresikan estimasi total upaya yang diperlukan untuk mengimplementasikan item product backlog atau pekerjaan lainnya secara lengkap
• Poin menunjukkan kompleksitas, volume pekerjaan, risiko atau ketidakpastian, serta jumlah pekerjaan
• Pengukuran kompleksitas bersifat relatif, sehingga tiap tim bisa menilai pekerjaan yang sama secara berbeda
• Karena sifat poin yang relatif, perbandingan antar tim tidak bermakna, dan ini adalah masalah yang sering muncul pada level manajemen

Volatilitas yang melekat

• Story point didasarkan pada deret Fibonacci, sehingga semakin tinggi nilainya semakin besar volatilitas yang direpresentasikan
• Menjumlahkan nilai poin yang volatil tidaklah bermakna, dan tindakan menjumlahkan poin dalam metrik velocity adalah keliru
• Menurut hukum Goodhart, saat sebuah pengukuran menjadi tujuan, pengukuran itu tidak lagi menjadi pengukuran yang baik

Masalah yang sudah diketahui

• Masalah story point sudah dikenal luas, tetapi tetap digunakan karena teknik estimasi alternatif juga mengalami masalah serupa
• Ron Jeffries, pencipta story point, menolaknya dan mengkritik penyalahgunaannya
• Dalam Scrum, "Commitment" diubah menjadi "Forecast", tetapi tetap masih disalahgunakan
• Muncul situasi paradoks ketika menyelesaikan lebih banyak pekerjaan daripada estimasi justru berujung pada teguran

Menentukan prioritas dengan ROI

• Bisnis memprioritaskan pekerjaan untuk mengoptimalkan resource (waktu, uang, alat, orang)
• Estimasi pengembangan diperlukan untuk menghitung biaya investasi, tetapi estimasi itu sendiri sulit dan mahal
• Software Estimation: Demystifying the Black Art adalah buku yang sangat baik tentang kesulitan estimasi

Output dari proses

• Proses estimasi story point menghabiskan banyak waktu, tetapi output-nya tidak bernilai
• Sesi grooming rutin memakan banyak waktu dan diterapkan secara beragam tanpa konsistensi antar tim
• Menyusun daftar pekerjaan yang bermakna lebih bernilai daripada menggunakan story point

Alternatif yang ditawarkan

• Mengestimasi dengan ukuran T-shirt bisa menjadi alternatif yang lebih baik, tetapi ini pun tetap memiliki masalah
• Estimasi berbasis waktu juga memiliki masalah serupa, karena waktu kerja aktual tim berbeda dengan waktu yang diharapkan dari sisi bisnis
• Pada tim kecil, estimasi waktu bisa bekerja dengan baik, tetapi ketika tim membesar, akurasi estimasi menurun
• Buku Donald Reinertsen, "The Principles of Product Development Flow", menawarkan alternatif
  • Intinya adalah mengoptimalkan aliran pekerjaan dengan berfokus pada pengelolaan antrean (Queue)
  • Perlu membuat perencanaan kapasitas dan mengamankan kapasitas buffer yang mampu menyerap volatilitas

Solusi

• Dimulai dari tim yang bersama-sama menganalisis pekerjaan, membaginya menjadi task kecil, dan menghilangkan ketidakpastian
• Daftar task menjadi antrean (Queue), dan total jumlah task merepresentasikan ukuran pekerjaan (Job Size)
• Alih-alih Story Point, gunakan rata-rata tingkat penyelesaian task (Average Task Rate) untuk estimasi
• Lacak pekerjaan berdasarkan kecepatan rata-rata penyelesaian task, dan hitung tingkat penyelesaiannya
• Jika task diperbarui mengikuti informasi atau umpan balik baru, estimasi akan menyesuaikan secara alami
• Pengembang tidak perlu menerima tekanan psikologis dari estimasi

Antrean (Queue) adalah indikator utama

• Rata-rata tingkat penyelesaian task, cycle time, velocity, dan sebagainya adalah indikator tertinggal, sedangkan Queue adalah indikator utama
• Jika ukuran Queue meningkat, masalah bisa dikenali dan ditangani lebih awal

Ringkasan

• Story Point menimbulkan kebingungan, tidak dapat diandalkan, dan pada dasarnya dirancang untuk gagal
• Sebaliknya, akan lebih bermakna dan bernilai jika tim meluangkan waktu untuk memahami masalah bersama, menghilangkan ketidakpastian, memecah pekerjaan menjadi task, dan mengelola Queue

Pendapat GN+

• Pendekatan pengelolaan antrean yang diajukan artikel ini tampak sebagai alternatif yang realistis untuk mengatasi kesulitan estimasi dalam pengembangan agile
• Namun, proses memecah task menjadi bagian-bagian kecil bisa menambah beban kerja bagi pengembang, dan pada tahap awal proyek dapat memerlukan lebih banyak waktu
• Selain itu, proses analisis task mensyaratkan partisipasi aktif pengembang dan penyampaian pendapat yang jujur
• Di sisi lain, juga bisa diharapkan adanya efek positif berupa tim pengembang memahami kebutuhan bisnis secara mendalam dan memikirkannya bersama

[heal9179]

Bukankah itu metodologi Kanban..?

[GN⁺]

Opini Hacker News

• Dari pengalaman pribadi, angka story point itu sendiri tidak penting, tetapi proses tim menilai kompleksitas pekerjaan sangat berguna

  • Menggunakan story point untuk memperkirakan waktu pengerjaan adalah metrik yang tidak andal
  • Saya cenderung menghindari story point karena berbagai alasan seperti perubahan tim dan domain, serta variabilitas pekerjaan non-pengembangan
  • Pada tim yang menggunakan story point, ini dipakai sebagai alat untuk berbagi pemahaman tentang pekerjaan

• Dalam panduan Scrum, perubahan dari "Commitment" menjadi "Forecast" bukan terjadi pada 2011

  • Setelah memeriksa panduan 2010 dan 2011, kata "Commitment" tidak ada di versi sebelum 2011
  • "Forecast" menggantikan "Estimate" dalam panduan 2020

• Memecah paket kerja menjadi unit atomik dan mengukur panjang antrean adalah persoalan di dimensi yang berbeda

  • Story point tetap bisa digunakan saat memurnikan paket kerja bersama tim
  • Memecah semua pekerjaan menjadi 1 story point terbukti tidak efisien
  • Menghubungkan panjang antrean dengan dampak variabilitas adalah konsep yang menarik

• Ada juga kasus ketika pendekatan waterfall dan estimasi berbasis waktu bekerja dengan baik

  • Dalam tim layanan profesional kecil, kebutuhan pelanggan didokumentasikan lalu didiskusikan dengan tim sebelum diestimasi dalam rentang waktu
  • Setelah disetujui pelanggan, prosesnya lanjut ke desain detail, pengembangan, QA, dan rilis
  • Selama 20 tahun prosesnya tidak berubah dan tim dinilai sangat produktif

• Story point merepresentasikan kompleksitas relatif dan ketidakpastian, bukan satuan waktu

  • Seharusnya cerita bisa diukur dengan angka yang besar
  • Di beberapa tim, tidak pernah diberikan lebih dari 7 poin
  • Di tempat lain, ada juga yang memberi 21, 30, atau 50 poin

• Story point pada praktiknya adalah satuan waktu yang kasar

  • Menyamakan story point dengan satuan waktu yang jelas bisa menyesatkan
  • Yang penting adalah memprediksi berapa lama pengembang akan menghabiskan waktu untuk pekerjaan itu
  • Agar analisis antrean berguna, kita perlu tahu estimasi waktu untuk setiap pekerjaan

• Saat pertama kali menggunakan Scrum, kami memakai Rally

  • Story point, estimasi waktu, dan waktu aktual semuanya dilacak
  • Setelah pindah ke Jira, pelacakan waktu hilang
  • Ketika estimasi waktu menjadi lebih akurat, lebih mudah menyeimbangkan beban kerja tim

• Story point berguna saat mendiskusikan kompleksitas pekerjaan, tetapi tidak cocok untuk mengukur velocity

  • Sebagai engineer baru, saya menyelesaikan banyak story point, tetapi manajemen mencoba menyesuaikannya
  • Sulit menilai pekerjaan yang kompleks dengan tepat

• Sulit memperkirakan proyek pengembangan perangkat lunak secara andal

  • Penting untuk memecah pekerjaan menjadi unit kecil bersama tim dan memperkirakannya dalam rentang waktu
  • Seiring proyek berjalan, penting untuk melaporkan daftar fitur dan rentang estimasi yang baru

• Estimasi berbasis waktu adalah pendekatan yang lebih baik

  • Story point pada akhirnya tetap dikonversi menjadi satuan waktu
  • Lebih efisien menghindari prosedur Scrum yang rumit dan langsung menyelesaikan pekerjaan