Estimasi Cerita Pengguna – Tabel Kemiripan

Cara Mengestimasi Cerita Pengguna untuk Pengembangan Agile

Mengestimasi cerita pengguna itu sulit! Bagaimana kita bisa mendapatkan estimasi terbaik dari ukuran cerita? Beberapa orang mengatakan ukuran terbaik harus diestimasi berdasarkan poin cerita, sementara yang lain lebih memilih diestimasi berdasarkan jam atau hari.

Memang mengestimasi itu sulit, tetapi ada beberapa konsep yang bisa membantu kita dalam proses estimasi cerita pengguna:

  1. Estimasi cerita pengguna secara relatif dari dua aspek
    • Usaha kerja
    • Risiko (seperti kompleksitas dan ketidakpastian)
  2. Estimasi cerita pengguna menggunakan poin cerita
  3. Tempatkan cerita pengguna tersebut di tabel kemiripan yang Anda percaya lebih tinggi dalam estimasi berdasarkan usaha kerja dan kompleksitas (risiko)
  4. Estimasi secara bertahap cerita pengguna lain yang kurang dikenal berdasarkan usaha kerja dan kompleksitas dengan membandingkannya dengan cerita-cerita yang telah diestimasi sebelumnya di tabel kemiripan.

Kemiripan 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 beberapacerita penggunayang paling kita merasa nyaman dalam hal estimasi (misalnya, 5 hari dan tingkat kepastian sedang). Dalam hal ini, Anda akan menempatkan cerita di tengah secara vertikal (tingkat kepastian ataurisikotingkat) dan secara horizontal (usahakerjasama 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 daripada yang dirujuk, atau lebih sedikit, dan memiliki ketidakpastian lebih besar atau lebih sedikit. Saat Anda menempatkan beberapa cerita pengguna lain ke dalam Tabel Kemiripan, Anda dapat membandingkannya untuk menentukan apakah penyesuaian tersebut logis atau tidak, lalu menyesuaikannya agar adil, dan selesai. Proses ini sedikit lebih seperti seni daripada teknik. Lakukan dan diskusikan dalam rapat tim, bukan dengan konfrontasi. Akurasi biasanya akan meningkat seiring tim menjadi lebih matang.

Estimate User Story with reference point

Bagaimana Tabel Kemiripan Menghitung? (Tonton Video

Untuk memahami bagaimana poin cerita dan hari diestimasi secara otomatis di Tabel Kemiripan, kita perlu memahami bahwa petak 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 mengembangkan sebuah cerita pengguna seharusnya tidak lebih dari panjang sprintsprint (jika tidak, maka cerita pengguna terlalu besar sehingga perlu dipecah, atau sprint terlalu pendek sehingga perlu diperpanjang), maka jumlah hari pada petak kanan bawah juga harus sama dengan panjang sprint. Berdasarkan asumsi ini, estimasi cerita dapat dihitung secara otomatis.

How Affinity Table Calculate?

Catatan: Pada contoh pertama di atas

Poin Cerita = Usaha x Risiko (misalnya 3 x 4 = 12)

Satuan Poin Cerita = Jumlah Total Poin / Panjang Sprint (misalnya 100 / 20) = 0.2

Hari Cerita (jam) = Poin Cerita / Satuan Poin Cerita (misalnya 12 x 0.2) = 2.4

Hilangkan Risiko dengan Proyek Spike

Menurut Kamus Agile, definisi Spike adalah:

“Tugas yang ditujukan untuk menjawab pertanyaan atau mengumpulkan informasi, bukan untuk menghasilkan produk yang dapat dikirimkanproduk. Terkadang sebuah cerita pengguna dibuat yang tidak dapat diperkirakan dengan baik hingga tim pengembangan melakukan pekerjaan nyata untuk menyelesaikan pertanyaan teknis atau masalah desain. Solusinya adalah membuat “spike”

Saat memperkirakan 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 diperkirakan secara adil.

Unduh dan Coba Sekarang!

Leave a Reply