Scrum memiliki beberapa ide menarik untuk mengatasi tantangan abadi estimasi akurat. Pada artikel ini saya ingin melihat kumpulan pendekatan tersebut: poin cerita, kecepatan burn-down, dan perencanaan poker. Scrum umumnya digunakan untuk proyek pengembangan perangkat lunak, tetapi ide-ide dalam artikel ini dapat diterapkan pada semua jenis pekerjaan.
Langkah 1 – Kumpulkan Cerita Pengguna Bersama
Di Scrum, setiap proyek dipecah menjadi kumpulan cerita pengguna. Ini adalah deskripsi dari satu fungsi yang harus dilakukan oleh perangkat lunak yang dikirimkan. Itu benar-benar persyaratan, tetapi seperti yang dikatakan Kent Beck dalam bukunya yang luar biasa “Extreme Programming Explained”, persyaratan terdengar wajib, dan banyak hal yang awalnya diminta oleh pengguna adalah “baik untuk dimiliki”. Setiap kisah pengguna menggambarkan perjalanan melalui perangkat lunak. Misalnya, sebuah cerita mungkin berkata, “Masuk menggunakan nama pengguna dan kata sandi Anda dan dibawa ke layar beranda.”
Tim perangkat lunak akan bekerja dengan klien mereka untuk memutuskan cerita pengguna mana yang akan disampaikan selama sprint kerja berikutnya. Sprint umumnya berlangsung sekitar 20 hari. Untuk melakukan ini, tim pengembangan perlu memperkirakan pekerjaan yang terlibat dengan setiap cerita pengguna. Di sinilah ide poin pengguna dan perencanaan poker berguna.
Langkah 2 – Perkirakan Setiap Cerita Pengguna Dalam Hal Poin Cerita
Salah satu jebakan perkiraan adalah usaha yang membingungkan (jumlah jam yang diperlukan untuk melakukan sesuatu) dengan durasi (selama periode waktu kalender yang diperlukan untuk melakukan sesuatu.) Misalnya, pengembang mungkin mengatakan cerita pengguna akan memakan waktu delapan jam untuk diselesaikan dan tim akan menganggap dia bisa melakukannya dalam satu hari. Namun ketika dia mulai bekerja, dia menemukan dia memiliki komitmen waktu lain, dan hanya dapat mengerjakan cerita selama satu jam sehari. Delapan hari kemudian dia menyelesaikan tugasnya. Durasi sulit diperkirakan; kita semua mengalami hari-hari baik dan hari-hari buruk dan beberapa hari memiliki lebih banyak gangguan daripada yang lain. Jawaban Scrum untuk ini adalah menjauhkan tim sepenuhnya dari memperkirakan waktu dan sebagai gantinya memperkirakan setiap cerita pengguna dalam hal poin cerita. Poin cerita adalah ukuran ukuran yang abstrak.
Cara terbaik untuk menggunakan poin cerita adalah memulai dengan cerita pengguna pertama dan memberinya ukuran tertentu, misalnya sepuluh poin cerita. Lalu, untuk cerita selanjutnya, ajukan pertanyaan, seberapa besar ini dibandingkan dengan yang pertama? Jika setengah dari ukuran itu diberikan lima poin cerita. Perbandingan relatif ini membantu menetapkan ukuran dalam pikiran estimator.
Langkah 3 – Memainkan Poker Perencanaan
Merencanakan poker adalah cara yang baik untuk memperkirakan poin cerita. Setiap anggota tim diberikan satu set kartu remi “poker”. Setiap kartu memiliki nomor di atasnya, mewakili perkiraan poin cerita. Biasanya setiap anggota tim memiliki sekitar 20 kartu. Daripada menggunakan kartu satu sampai dua puluh, seri fibonacci sering digunakan (1,2,3,5,8,13,21,34 dan seterusnya). Variasi kesenjangan antara angka fibonacci mewakili ketidakpastian yang melekat dengan estimasi.
Permainan “poker” kemudian dimulai. Kisah pengguna disajikan kepada tim, kemudian setiap anggota tim memilih kartu yang mewakili perkiraan mereka dan menempatkannya jika menghadap ke bawah di atas meja. Semua kartu dibalik secara bersamaan. Ini penting, karena jika tidak, perkiraan satu orang mungkin memengaruhi perkiraan orang lain. Diskusi berikut di mana pengembang membenarkan perkiraan mereka. Proses ini diulang beberapa kali.
Langkah 4 – Menggunakan Kecepatan untuk Mengonversi Poin Cerita Menjadi Durasi
Poin cerita bersifat abstrak, jadi sekarang tim mengonversinya menjadi durasi untuk melihat berapa banyak waktu yang diperlukan untuk mengembangkan kumpulan cerita pengguna dengan ukuran poin pengguna tertentu. Di sinilah konsep kecepatan Scrum masuk. Kecepatan adalah ukuran seberapa banyak pekerjaan yang dapat dilakukan tim dalam hari-hari biasa. Dengan kata lain
Kecepatan = Poin cerita/Durasi
Jadi, jika cerita pengguna besar 30 poin cerita dan kecepatan rata-rata tim adalah tiga poin cerita per hari, cerita pengguna harus diselesaikan dalam 10 hari kalender. Pertanyaan selanjutnya tentu saja berapa kecepatan tim Anda? Cara terbaik untuk memperkirakan ini adalah dengan melakukan beberapa sprint dan melihat berapa banyak pekerjaan yang dilakukan tim pada hari rata-rata. Jika ini adalah sprint pertama, tim harus berkumpul dan membuat perkiraan yang masuk akal tentang kemungkinan kecepatan mereka (mungkin dengan menggunakan perencanaan poker lagi).
Bagan burndown adalah alat yang berguna untuk membantu tim memantau pekerjaannya dan menghitung kecepatannya. Mereka menunjukkan, setiap hari, berapa banyak poin pengguna yang masih harus diselesaikan. Setiap hari tim diminta menghitung ulang berapa banyak poin cerita yang tersisa dan angka ini diplot pada grafik. Angka ini mudah-mudahan turun, meskipun terkadang saat tim mulai bekerja, mereka akan menyadari bahwa perkiraan awal mereka terlalu rendah. Kemiringan grafik burndown adalah kecepatan tim.
Memperkirakan selalu sulit, tidak ada yang memiliki bola kristal untuk dapat melihat ke masa depan, tetapi gagasan Scrum tentang poin pengguna dan perencanaan poker memberikan pendekatan yang membantu diskusi dan pemikiran kolaboratif yang seharusnya memberikan prediksi yang lebih akurat. Memantau kecepatan tim menggunakan bagan burndown membantu memberikan informasi historis yang berguna untuk perkiraan di masa mendatang dan juga transparansi di mana tim berada dalam proses pengembangan pada waktu tertentu.