Scrum mengestimasi ulang cerita

Setiap hari, setelah stand-up , tim saya dan saya memperbarui perkiraan kami untuk setiap cerita. Saya merasa ada yang salah dengan cara kami melakukannya, jadi saya butuh bantuan Anda.

Inilah cara kami melakukannya:

Perkiraan Story A: 24 jam (8 jam per hari - kami menggunakan "hari ideal" sebagai ukuran)

• Hari N: pengembang mulai mengerjakan Story A di pagi hari (8 jam kerja selesai di akhir hari)
• Hari N + 1: Perkiraan ulang cerita A = 16 jam (satu hari kerja diambil dari Cerita A, dari hari N)
• Hari N + 2: Perkiraan kembali Story A = 8 jam (satu hari kerja dihilangkan dari Story A, dari hari N + 1)
• Hari N + 3: Cerita A harus dilakukan sekarang. Tapi ternyata tidak. Pengembang menganggap perlu waktu 3 jam lagi untuk menyelesaikannya. Kami memperbarui cerita di papan tulis dan membakar sesuai.
• Hari N + 4: Cerita A menghabiskan seluruh hari untuk selesai, bukan hanya 3 jam! Sekarang sudah selesai. Perbedaannya, 5 jam, sepenuhnya tidak diperhitungkan dalam perencanaan kami.

Bagaimana seharusnya kita setiap hari memperkirakan kembali cerita kita?

Perbedaannya, 5 jam, sepenuhnya tidak diperhitungkan dalam perencanaan kami.

Ya, itu dianggap secara implisit karena tugas-tugas berikut ini tertunda. Jika ada grafik burndown hanya untuk pengembang itu, Anda akan melihat bahwa kurva tetap "datar" untuk satu hari sementara itu akan turun jika pengembang telah menyelesaikannya cukup awal untuk mengambil tugas lain.

Tidak ada yang salah dengan cara Anda memperkirakan kembali selama pertemuan harian, estimasi ulang lebih tentang mencari tahu jika kita bisa membuatnya untuk akhir sprint daripada tentang melacak keterlambatan tepat setiap tugas. Yang Anda butuhkan di Scrum untuk dapat menyesuaikan rencana Anda setiap hari adalah sesuatu yang menunjukkan kemajuan Sprint dan seberapa jauh Anda dari memenuhi tujuan Sprint (biasanya, grafik burndown).

Pertanyaan yang harus Anda tanyakan adalah: Haruskah kita menaksir ulang cerita kita?

Saya berpendapat bahwa Anda harus mengizinkan "sihir" Agile untuk menyeimbangkan estimasi di bawah dan di atas iterasi saat menghitung kecepatan Anda untuk yang berikutnya (yang merupakan satu-satunya alasan untuk mengoreksi nilai). Lihat Mike Cohn's Agile Estimating and Planning untuk info lebih lanjut.

Namun, ada kasus di mana Anda harus menaksir kembali: di mana sesuatu yang telah Anda pelajari tentang kategori pekerjaan menyesuaikan semua perkiraan ke depan.

misalnya. Jika menambahkan kolom ke basis data diperkirakan membutuhkan waktu yang ideal, tetapi ternyata membutuhkan waktu 3 jam karena beberapa faktor yang tidak ada yang dipertimbangkan dan sepertinya faktor itu akan berlaku setiap kali Anda menambahkan bidang ke basis data maka semua perkiraan untuk pekerjaan yang sifatnya harus disesuaikan, termasuk yang Anda kerjakan.

Apa yang saya temukan paling efektif adalah:

• Cerita ukuran dengan poin (atau ukuran T-shirt.)
• Perkirakan kembali setiap cerita dalam jaminan produk kapan saja (tetapi terutama tepat sebelum perencanaan sprint.)
• Jangan menaksir ulang cerita yang dijadwalkan untuk sprint ini - jangan ragu untuk mengemukakan kekhawatiran saat standup, tetapi jangan ubah estimasi.
• Gunakan cuaca kemarin untuk menjadwalkan sprint

Jika cerita memasuki sprint dengan perkiraan palsu, perkiraan ulang perencanaan pra-sprint akan memungkinkan Anda memperbaikinya sebelum menjadi masalah. Jika cerita memakan waktu lebih lama dari yang diharapkan karena tim terlalu optimis, cuaca kemarin akan membuat Anda tetap pada jalurnya.

Perkiraan ulang harian tentang apa yang tersisa cenderung benar-benar palsu, seperti yang Anda jelaskan dalam pertanyaan Anda. Pekerjaan selesai / tersisa adalah nomor palsu yang dirancang agar terlihat seperti Anda bekerja "cukup keras". Jauh lebih baik untuk bertanya, "Kapan Anda pikir Anda akan selesai," dan jelaskan bahwa jika ada masalah dengan sebuah cerita, bahwa tim akan melangkah untuk membantu.

Saya pikir ini bukan masalah. Sebaliknya, itu mungkin karena kurangnya pengalaman. Semakin banyak Anda mengikuti scrum, semakin banyak pengembang membiasakan diri untuk memberikan perkiraan preciser. Ini adalah pengalaman kami menerapkan scrum setelah 5 bulan.

Dalam merencanakan sesi poker , pengembang kami menyarankan estimasi yang sangat beragam untuk setiap PBI dan setiap tugas dalam sprint pertama. Namun, sekarang, kami hampir sama dalam hal waktu dan estimasi. Berapa lama Anda menggunakan scrum? Jika tidak sebanyak itu, berikan waktu. Tetapi jika itu adalah waktu yang lama, maka seperti yang disarankan @pdr, pertimbangkan untuk menambahkan margin tambahan untuk tugas-tugas dengan risiko yang lebih tinggi . Misalnya, setiap kali tim kami ingin membuat browser lintas UI, kami melewati estimasi kami. Karenanya, kami selalu mengalikan estimasi tugas lintas browser dengan faktor untuk memastikan kami dapat mengatasinya.

Menilai kembali cerita pengguna yang berkomitmen selama sprint tidak masuk akal. Itu hanya membuang waktu Anda. Anda sudah melakukan komitmen dan tidak masalah apakah Anda melakukan estimasi ulang atau tidak.

Situasi yang berbeda adalah dengan cerita pengguna yang tidak berkomitmen pada sprint saat ini. Dari waktu ke waktu, baik untuk membuat estimasi ulang (tidak lebih dari sekali per sprint sebelum perencanaan). Situasi mengapa estimasi ulang bisa masuk akal:

• Pemilik produk mengubah cerita pengguna apa pun
• Pemilik produk memecah atau menggabungkan cerita pengguna apa pun
• Pemilik produk menambahkan kisah pengguna
• Anda memiliki beberapa pengetahuan tambahan yang tidak tersedia selama cerita pengguna terakhir
• Anda menemukan bahwa beberapa cerita pengguna terkait dan Anda sudah melakukan bagian dari yang lain belum berkomitmen
• dll.

Anda tidak perlu memperkirakan ulang setiap kisah pengguna tetapi Anda bisa. Untuk estimasi ulang lengkap, Anda biasanya memerlukan metode cepat. Perencanaan poker bisa sangat lambat, tidak efisien, membosankan dan kadang-kadang juga tidak akurat jika Anda mengambil lebih dari 10-20 cerita untuk diestimasi. Alternatif dapat berupa estimasi Sihir .