Ketika berbicara tentang estimasi agile, Anda tidak bisa tidak menyebutkan prinsip dasarnya: menggunakan unit estimasi relatif (seperti story points), mempromosikan diskusi mendetail tentang konten user stories, membentuk konsensus dan komitmen terhadap solusi, serta meningkatkan tim melalui kolaborasi yang kohesif.
Banyak tim agile di sekitar saya menggunakan “planning poker” untuk memperkirakan story points. Meskipun metode ini populer, ia juga memiliki keterbatasan.
Contohnya:
- Fungsi yang akan diestimasi terlalu besar, dan tidak mudah untuk memperkirakan dengan “planning poker”;
- 300 user stories muncul;
- User story yang akan diestimasi tidak memiliki cukup informasi untuk referensi;
- Waktunya terbatas, tidak ada waktu untuk memperkirakan seluruh daftar permintaan produk.
Jadi, artikel ini tidak hanya memperkenalkan metode estimasi agile paling populer “planning poker”, tetapi juga 6 metode estimasi agile lainnya untuk memenuhi semua kebutuhan Anda dalam estimasi user story.
1. Planning Poker
Semua peserta menggunakan kartu bermain bernomor untuk memperkirakan cerita pengguna, memberikan suara secara anonim saat memperkirakan, mendiskusikan jika ada ketidaksepakatan besar, dan kemudian memberikan suara lagi, sampai seluruh tim mencapai konsensus tentang akurasi estimasi. Penggunaan planning poker memiliki keterbatasan dan paling cocok untuk tim kecil (5–8 orang) dan sejumlah kecil user stories (hingga 10).
Tip:meskipun ini bukan aturan, sangat disarankan untuk memecah user stories dalam backlog produk tidak lebih besar dari 13 poin; sehingga tim Anda dapat dengan jelas memahami user stories hingga tingkat detail yang dapat diestimasi dengan nyaman.
2. Ukuran T-shirt
Gunakan ukuran T-shirt untuk memperkirakan ukuran cerita pengguna: XS, S, M, L, XL. Ukuran masing-masing ukuran mewakili kebutuhan untuk diskusi yang terbuka dan jujur. Metode ini cepat dan mudah, dan Anda dapat memperkirakan ukuran daftar permintaan produk dengan cara yang berani.
Tip:Metode ini cocok untuk memperkirakan daftar permintaan besar dari user stories besar, terutama ketika beberapa tim Scrum bekerja di sekitar produk.
3. Dot Vote
Metode ini cocok untuk memperkirakan user stories kecil, dan metode itu sendiri sangat sederhana dan efektif. “Dot voting” adalah cara untuk membuat keputusan, tetapi Anda juga dapat menggunakannya untuk memperkirakan user stories. Metodenya adalah: setiap orang diberikan beberapa catatan post-it, bebas memilih user stories mana yang akan dipilih. Semakin banyak titik yang didapat user story, semakin banyak volume yang diwakilinya.
Tip:Metode ini dapat digunakan di tim besar maupun kecil, tetapi Anda harus membatasi jumlah user stories yang diestimasi.
4. Sistem Bucket
Misalkan Anda memiliki sejumlah besar user stories yang perlu diestimasi, dan Anda ingin mempercepat seluruh proses. Sebenarnya, Anda mencari estimasi yang lebih efisien daripada planning poker, maka “sistem bucket bisa menjadi pilihan yang diinginkan.”
Pertama, siapkan beberapa “bucket” dalam urutan berurutan dari “kartu planning poker”. Kemudian, tim menulis user story yang akan diestimasi di catatan post-it dan memasukkannya ke dalam estimasi “bucket”.
3. Metode Tiga Poin
Estimasi 3 poin termasuk dalam area pengetahuan manajemen waktu. Ini juga dapat digunakan selama Estimasi Biaya. Masalah dengan estimasi titik tunggal adalah bahwa mereka jarang benar. Estimasi tiga poin adalah estimasi yang lebih baik, dibandingkan dengan estimasi titik tunggal.
Estimasi titik tunggal hanya memberi Anda satu angka — misalnya,
Kembangkan: Berapa lama waktu yang dibutuhkan untuk menyelesaikan fitur proses pemesanan?
Seberapa dapat diandalkannya ini5 hari estimasi? Itu akan tergantung pada pengembang, dan apakah tugas ini telah dilakukan sebelumnya atau tidak? Jika ini adalah tugas rutin, dan telah dilakukan berkali-kali, estimasi titik tunggal mungkin adalah cara yang tepat. Tetapi jika ini adalah sesuatu yang belum pernah dilakukan, atau merupakan aktivitas baru, atau insinyur baru dalam aktivitas ini, angka ini mungkin saja tidak benar. Dalam kasus seperti itu, memilih estimasi tiga poin akan memberi Anda lebih banyak keandalan.
Estimasi tiga poin melihat estimasi yang paling optimis (O), estimasi yang paling mungkin (M), dan estimasi pesimis (Estimasi paling tidak mungkin) atau (L).
6. Estimasi Afinitas
Estimasi afinitas adalah untuk menemukan kesamaan dari user stories yang akan diestimasi. Tugas tim adalah mengelompokkan user stories yang serupa. Cara terbaik untuk “menemukan kesamaan” adalah dengan memvisualisasikan proses dan menggabungkan subtotal menjadi kelompok besar.
Tip:Metode ini bekerja paling baik dalam kelompok kecil orang dan sejumlah kecil user stories, Anda harus memberikan estimasi yang berbeda untuk kelompok yang berbeda.
7. Metode Pengurutan
Pendekatan ini memungkinkan Anda untuk memiliki penilaian yang relatif akurat tentang ukuran relatif dari cerita pengguna. Jika sekelompok kecil ahli melakukan ini, itu akan bekerja dengan baik.
Berikut caranya: Tempatkan semua user stories pada label tick dari rendah ke tinggi dalam urutan apa pun, dan setiap peserta dapat memindahkan user story pada skala, hanya memindahkan satu bingkai rendah atau tinggi untuk setiap gerakan. Atau menyerah satu putaran. Ulangi proses ini sampai semua anggota tim tidak ingin memindahkan user story atau menyerah satu putaran.
Tip:Metode pengurutan ini dapat memperoleh estimasi ukuran butiran halus, yang cocok untuk kelompok kecil orang dan sejumlah besar user stories.
Ringkasan
Tujuan artikel ini adalah untuk memperkenalkan Anda pada keberadaan metode-metode ini. Sebelum penggunaan harian, Anda harus mencoba berbagai metode berdasarkan cerita pengguna Anda sendiri dan ukuran staf Anda.
Jika Anda tertarik dengan metode-metode ini, silakan tinggalkan pesan di bagian komentar. Saya dapat menjelaskan metode tersebut dengan lebih rinci dalam artikel terpisah.
Artikel Lainnya dalam Teknik dan Artefak Scrum
- Apa itu Artefak Scrum?
- Definisi Selesai vs Kriteria Penerimaan
- Apa itu Definisi Siap dalam Scrum?
- Bagaimana Menulis Tujuan Sprint?
- Apa itu Product Backlog dalam Scrum? Siapa yang Bertanggung Jawab atasnya?
- Bagaimana Menghaluskan Product Backlog?
- Apa itu Sprint Backlog dalam Scrum?
- Bagaimana Memprioritaskan Product Backlog Menggunakan Metode MoSCoW
- Bagaimana Memprioritaskan Product Backlog Menggunakan Metode 100 Poin?
- Apa itu Tujuan Sprint dalam Scrum?
- Apa itu Grafik Burndown dalam Scrum?
- Apa itu Template Peran-Fitur-Alasan?
- Inkrement Sprint vs Produk yang Potensial Dikirim vs MVP vs MMP
- Tulis Tujuan SMART & INVEST untuk Cerita Pengguna
- Apa itu DEEP dalam Product Backlog?
- Bagaimana Menulis Visi Produk untuk Proyek Scrum?
- Bagaimana Menggunakan Papan Scrum untuk Pengembangan Agile?
- Siapa yang Membuat Item Product Backlog atau Cerita Pengguna dalam Scrum?
- Apa itu Estimasi Agile?
- Apa itu Story Point dalam Agile? Bagaimana Mengestimasi Cerita Pengguna?
This post is also available in Deutsch, English, Español, فارسی, Français, 日本語, Polski, Portuguese, Ру́сский, Việt Nam, 简体中文 and 繁體中文.