Poin pengguna dan perencanaan poker – beberapa ide estimasi dari Scrum
Scrum memiliki beberapa ide menarik untuk mengatasi tantangan estimasi akurat yang abadi. Pada artikel ini, saya ingin melihat kumpulan pendekatan tersebut: poin cerita, tingkat pembakaran, 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 bagian fungsionalitas yang harus dilakukan oleh perangkat lunak yang dikirimkan. Itu memang persyaratan, tetapi seperti yang dikatakan Kent Beck dalam bukunya yang luar biasa “Extreme Programming Explained”, persyaratan terdengar wajib, dan sebagian besar yang diminta pengguna pada awalnya adalah “menyenangkan untuk dimiliki”. Setiap kisah pengguna menggambarkan perjalanan melalui perangkat lunak. Misalnya, ceritanya mungkin berbunyi: “Masuk menggunakan nama pengguna dan kata sandi Anda dan Anda akan dibawa ke layar beranda.”
Tim perangkat lunak akan bekerja dengan pelanggan mereka untuk memutuskan cerita pengguna mana yang akan disampaikan selama sprint kerja berikutnya. Sprint biasanya berlangsung sekitar 20 hari. Untuk melakukannya, tim pengembangan perlu mengevaluasi pekerjaan yang terlibat dalam setiap kisah pengguna. Berikut adalah beberapa ide berguna tentang poin pengguna dan perencanaan poker.
Langkah 2 – Evaluasi setiap cerita pengguna dalam hal poin cerita
Salah satu kendala dalam memperkirakan adalah upaya yang membingungkan (jumlah jam yang diperlukan untuk melakukan sesuatu) dengan durasi (jumlah waktu kalender yang diperlukan untuk melakukan sesuatu.) Misalnya, pengembang mungkin mengatakan bahwa cerita pengguna akan memakan waktu delapan jam untuk diselesaikan , dan tim akan menganggap mereka dapat melakukannya dalam sehari. Namun, ketika dia pergi bekerja, dia menemukan bahwa 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 agar tim menjauh dari memperkirakan waktu sama sekali dan malah 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 pertama pengguna dan memberikan ukuran tertentu, misalnya sepuluh poin cerita. Lalu, untuk cerita selanjutnya, ajukan pertanyaan seberapa besar yang ini dibandingkan dengan yang pertama? Jika setengahnya, itu diberikan lima poin. Perbandingan relatif ini membantu melabuhkan ukuran dalam pikiran penilai.
Langkah 3 – Memainkan Poker Perencanaan
Perencanaan poker adalah cara yang baik untuk memperkirakan poin cerita. Setiap anggota tim menerima satu set kartu “poker”. Setiap kartu memiliki nomor di atasnya, yang mewakili estimasi poin cerita. Biasanya setiap anggota tim memiliki sekitar 20 kartu. Alih-alih menggunakan kartu dari satu sampai dua puluh, deret Fibonacci (1,2,3,5,8,13,21,34 dan seterusnya) sering digunakan. Variasi kesenjangan antara angka Fibonacci mewakili ketidakpastian yang melekat dengan perkiraan.
Kemudian permainan “poker” dimulai. Tim diberikan cerita pengguna, kemudian setiap anggota tim memilih kartu yang mewakili penilaian mereka dan meletakkannya menghadap ke bawah di atas meja. Semua kartu diputar secara bersamaan. Hal ini penting, karena jika tidak, penilaian seseorang dapat mempengaruhi penilaian orang lain. Diskusi berikut di mana pengembang membenarkan penilaian mereka. Proses ini diulang beberapa kali.
Langkah 4 – Menggunakan kecepatan untuk mengubah poin cerita menjadi durasi
Poin cerita bersifat abstrak, jadi sekarang tim mengubahnya menjadi durasi untuk melihat berapa lama waktu yang dibutuhkan untuk mengembangkan kumpulan cerita pengguna dengan ukuran pengguna tertentu. Di sinilah konsep kecepatan Scrum berperan. Velocity adalah ukuran berapa banyak pekerjaan yang dapat dilakukan tim dalam hari-hari biasa. Dengan kata lain
Kecepatan = Poin/Durasi Cerita
Jadi, jika cerita pengguna berukuran besar 30 poin, dan kecepatan rata-rata tim adalah tiga poin cerita per hari, cerita pengguna harus diselesaikan dalam 10 hari kalender. Pertanyaan selanjutnya tentu saja seberapa cepat tim Anda? Nah, cara terbaik untuk menilai ini adalah dengan melakukan beberapa sprint dan melihat berapa banyak rata-rata pekerjaan yang dilakukan tim per hari. Jika ini adalah sprint pertama, tim perlu berkumpul dan membuat perkiraan yang masuk akal tentang kemungkinan kecepatan mereka (mungkin menggunakan poker perencanaan lagi).
Bagan burndown adalah alat yang berguna untuk membantu tim melacak pekerjaan mereka dan menghitung kecepatannya. Mereka menunjukkan, setiap hari, berapa banyak poin pengguna yang masih perlu diselesaikan. Setiap hari tim diminta menghitung ulang berapa banyak poin cerita yang tersisa dan angka ini diplot pada grafik. Mudah-mudahan angka ini akan turun, meski terkadang saat tim mulai bekerja, mereka akan menyadari bahwa perkiraan awal mereka terlalu rendah. Kemiringan grafik burndown adalah kecepatan tim.
Estimasi selalu sulit, tidak ada yang memiliki bola kristal untuk melihat ke masa depan, tetapi ide Scrum tentang poin pengguna dan perencanaan poker memberikan pendekatan yang membantu diskusi kolaboratif dan curah pendapat yang akan menghasilkan prediksi yang lebih akurat. Melacak kecepatan tim dengan bagan burndown membantu memberikan informasi historis yang berguna untuk penilaian di masa mendatang, serta transparansi di mana tim berada dalam proses pengembangan pada waktu tertentu.