Cara Mengestimasi Cerita Pengguna Menggunakan Tabel Affinitas Otomatis

Poin Cerita atau Hari, atau Keduanya?

Orang sering berdebat tentang apakah harus menggunakan poin cerita atau jam (atau hari) dalam estimasi cerita. Beberapa orang percaya bahwa kita tidak perlu menghitung poin cerita dan kecepatan tim sama sekali. Nah, tim yang berbeda mungkin memiliki pendapat yang berbeda, tetapi tetap saja, sebagian besar proyek Agile melakukan estimasi cerita dan menganggapnya sebagai salah satu alat yang sangat berguna dalam menyelesaikan proyek tepat waktu dan sesuai anggaran.

Tabel Affinitas untuk Estimasi Cerita

Di Visual Paradigm, kami tidak menganggap estimasi cerita sebagai proses yang penuh konflik atau negosiasi, melainkan sebagai proses pembentukan tim yang membuat kolaborasi tugas dan beban kerja menjadi jelas dan transparan bagi semua anggota tim. Alat cerita pengguna memberdayakan tim dengan Tabel Affinitas untuk mengotomatisasi proses estimasi cerita bersamaan dengan penghapusan spike. Selain itu, Tabel Affinitas visual mendukung estimasi real-time dengan menggunakan poin cerita dan jam cerita secara bersamaan. Saat Anda menyeret cerita di sepanjang tabel, baik poin cerita maupun jam akan ditampilkan secara bersamaan selama cerita masih bergerak. Cukup letakkan cerita di kotak yang menurut tim Anda cocok untuk estimasi.

Bagaimana Tabel Affinitas Menghitung?

Untuk memahami bagaimana poin cerita dan hari diestimasi secara otomatis dalam Tabel Affinitas, kita perlu memahami bahwa kotak-kotak horizontal mewakili usaha kerja, meningkat dari kiri ke kanan, dan kompleksitas pengembangan cerita (seperti teknologi baru, bidang baru, dan sebagainya) meningkat dari atas ke bawah.

Karena jumlah hari maksimum untuk pengembangan cerita pengguna seharusnya tidak lebih dari panjang sprint (jika tidak, maka cerita pengguna terlalu besar sehingga perlu dibagi, atau sprint terlalu pendek sehingga perlu diperpanjang), maka jumlah hari pada kotak kanan bawah juga harus sama dengan panjang sprint. Berdasarkan asumsi ini, estimasi cerita dapat dihitung secara otomatis.

Affinitas Cerita Pengguna untuk Estimasi

Estimasi cerita pengguna tidak akan pernah akurat 100 persen, dan pada kenyataannya tidak ada metode yang bisa mencapai hal tersebut. Untuk meningkatkan akurasi estimasi, kita mulai dengan menentukan panjang sprint (misalnya dua minggu, atau 10 hari kerja) dan melakukan estimasi pada beberapa cerita pengguna yang menurut kita paling nyaman untuk diestimasi (misalnya 5 hari dan tingkat kepastian sedang). Dalam kasus ini, Anda akan menempatkan cerita di tengah secara vertikal (tingkat kepastian atau tingkat risiko) dan secara horizontal (usaha kerja setara dengan 5 hari, atau setengah dari panjang sprint, yaitu 10 hari). Anda kemudian dapat menggunakannya sebagai titik acuan dalam mengestimasi cerita pengguna lainnya. Tanyakan pada diri sendiri apakah cerita pengguna ini membutuhkan usaha lebih besar dari yang dirujuk, atau lebih sedikit, dan memiliki tingkat ketidakpastian yang lebih tinggi atau lebih rendah. Saat Anda menempatkan beberapa cerita pengguna lain ke dalam Tabel Affinitas, Anda dapat membandingkan beberapa cerita pengguna untuk menentukan apakah penyesuaian tersebut logis atau tidak, lalu mengatur ulang agar menjadi adil, dan selesai. Proses ini sedikit lebih seperti seni daripada rekayasa. Lakukan dan diskusikan dalam rapat tim, bukan dalam bentuk konfrontasi. Akurasi biasanya akan meningkat seiring tim menjadi lebih matang.

Hilangkan Risiko dengan Spike Proyek

Menurut Kamus Agile, definisi Spike adalah:

“Tugas yang ditujukan untuk menjawab pertanyaan atau mengumpulkan informasi, bukan untuk menghasilkan produk yang dapat dikirim. Terkadang muncul cerita pengguna yang tidak dapat diestimasi dengan baik hingga tim pengembangan melakukan pekerjaan nyata untuk menyelesaikan pertanyaan teknis atau masalah desain. Solusinya adalah membuat ‘spike’, yaitu suatu pekerjaan yang tujuannya adalah memberikan jawaban atau solusi.”

Saat mengestimasi cerita pengguna, kita tidak hanya mempertimbangkan usaha pengembangan, tetapi juga mempertimbangkan risiko dan ketidakpastian yang terlibat. Seringkali, spike dibuat sebelum dimulainya sprint secara resmi untuk mengelola pekerjaan yang harus dilakukan agar beberapa cerita pengguna lain dapat diestimasi secara adil.