Memperkirakan cerita didasarkan pada gagasan bahwa, seiring waktu, sebuah tim mendapatkan pengalaman dalam menyelesaikannya. Dengan itu akurasi ditingkatkan dan kecepatan dapat ditetapkan untuk mengukur kecepatan tim. Metodologi yang sempurna untuk membuat prognosis yang andal untuk sprint di masa depan.
Bug adalah fakta kehidupan perusahaan pengembangan perangkat lunak. Sementara saya setuju bahwa bug semua harus ditangkap selama pengembangan cerita, menerima bahwa ini tidak dapat dicapai setiap saat, harus menjadi sesuatu yang harus direncanakan oleh setiap tim. Alih-alih dengan keras kepala berpikir bahwa proses itu harus menguasai tim, itu harus sebaliknya.
Tentu saja, bug atau cerita, dari sisi bisnis tidak masalah apa yang dihadapi tim. Keduanya dapat menghasilkan jumlah nilai yang sama bagi pemilik produk.
Di tim kami, kami telah bereksperimen dengan beberapa teknik untuk memperkirakan bug:
- Memperkirakan bug yang sama sekali tidak dikenal
- Hanya memperkirakan bug yang sudah dianalisis
- Mengalokasikan waktu untuk memperbaiki bug dan tidak memperkirakan bug, tetapi rangking mereka hanya berdasarkan nilai bisnis
Dengan 1. kita gagal secara salah. Untuk sebagian besar bug, kami menemukan 90% waktu dihabiskan untuk analisis bug. Setelah itu perbaikan bug dapat diperkirakan dengan cara yang sama seperti sebuah cerita. Dengan merencanakan bug menjadi sprint, kami membuat kesalahan bahwa ruang lingkup yang tidak diketahui memengaruhi resolusi cerita hingga titik di mana hampir setiap sprint yang kami lakukan dengan cara ini gagal.
Berdasarkan opsi estimasi teknik rasio 90/10 (analisis terhadap bug) 2. berarti kami harus merencanakan analisis yang bukan sesuatu yang dicakup untuk perencanaan sprint (kami telah belajar dari opsi 1, tetapi tidak memiliki solusi nyata cara melanjutkan dengan bug yang dianalisis). Hasilnya adalah bahwa analisis bug tidak dilakukan karena sprint berfokus pada item yang direncanakan sebagai gantinya. Tim tidak punya waktu untuk fokus pada bug dari backlog. Jadi pada akhirnya mereka juga tidak selesai.
Dengan merangkul ketidakpastian, kami sekarang telah memilih opsi 3. Kami telah membagi tumpukan produk menjadi bagian cerita / tugas reguler yang dapat diperkirakan oleh tim menggunakan poin cerita dan tumpukan bug. Dalam tumpukan bug, pemilik produk memberi peringkat bug berdasarkan nilai bisnis dan penilaian tim yang sangat kasar. Tim ini memungkinkan untuk mengalokasikan sejumlah waktu selama sprint yang dapat dihabiskan untuk fokus pada bug. Pemilik produk tidak mengetahui hasil pasti karena tidak mungkin merencanakannya sebelumnya. Rasio backlog bug dibandingkan backlog biasa dapat disesuaikan untuk setiap sprint tergantung pada status saat ini dari setiap backlog dan pentingnya dan nilai bisnis dari konten.
Dengan menghilangkan ketidakpastian itu membebaskan tim lagi. Sprint tidak terganggu oleh bug yang tidak dikenal. Dengan memisahkan bug ke dalam tumpukan berbeda, keduanya meningkatkan fokus sprint tim reguler dan membuat kami menyelesaikan bug yang mengandung nilai bisnis yang signifikan juga.
Jadi itu tergantung apakah poin cerita cocok untuk Anda. Saya akan mencoba memperkirakan bug menggunakan poin cerita terlebih dahulu. Jika gagal coba opsi saya 3. Ini telah membuat tim kami (lebih dari 30 sprint lama) fokus pada bug yang lebih lama yang mengandung nilai bisnis yang hebat. Hal ini juga membebaskan kami dari upaya memberikan sesuatu yang tidak bisa diperkirakan oleh tim. Itu merangkul hal-hal yang tidak diketahui yang membuat kami lebih dekat dengan kenyataan dan juga membuat sprint kami berhasil lagi sambil memberikan potongan besar (berdasarkan rasio bug ke cerita) dari nilai bisnis melalui perbaikan bug. Rasio yang kami gunakan baru-baru ini adalah 50/50.