Apa cara terbaik untuk memperkirakan poin cerita dalam scrum?

Saya suka cara perencanaan poker bekerja di awal setiap proyek, membiarkan Anda membandingkan dan mendiskusikan detail masing-masing cerita satu sama lain.

Salah satu masalah yang saya perhatikan dengan hal ini adalah bahwa seiring waktu dan ketika Anda mendapatkan lebih banyak pengalaman dengan domain masalah, Anda cenderung memilih lebih sedikit poin untuk setiap cerita, yaitu, sebuah cerita yang bernilai 5 atau 8 pada awalnya. proyek sekarang mungkin bernilai 3.

Bagaimana Anda menghindari atau mengatasi masalah ini dengan cara sebaik mungkin? Apakah ada cara yang lebih baik untuk memperkirakan? Haruskah ceritanya selalu tetap sama, atau apakah poin cerita ini berkurang ok?

Saya pikir itu bukan masalah besar.

Ada dua hal jelas yang bisa menyebabkan itu. Pertama, Anda mengalami deflasi ringan. Yang lain adalah bahwa tim Anda sebenarnya semakin cepat. (Saya harap ini yang terakhir!)

Either way, itu seharusnya tidak menjadi masalah besar. Dua kegunaan utama kecepatan adalah mencari tahu berapa banyak pekerjaan yang harus dilakukan dalam iterasi berikutnya, dan membuat perkiraan kasar tanggal pengiriman untuk potongan pekerjaan yang lebih besar. Tak satu pun dari mereka yang dirugikan oleh kecepatan yang berubah secara bertahap. Memang, jika kecepatan yang ditingkatkan datang dari menjadi lebih baik, maka angka baru Anda menyajikan gambaran yang lebih benar dari kapasitas tim.

Jika kecepatan berubah terlalu cepat untuk kenyamanan, maka satu respons adalah cerita kanonik. Telusuri beberapa bulan terakhir, pilih masing-masing 3 cerita untuk mewakili level poin yang Anda gunakan. Letakkan mereka di dinding tempat Anda melakukan estimasi. Kemudian saat Anda memperkirakan, gunakan itu sebagai perbandingan dengan cerita yang Anda hadapi. Itu harus mengurangi drift dan volatilitas dalam estimasi Anda.

Pada dasarnya, ini bukan masalah besar, karena sebagian besar dari hal-hal ini akan keluar dalam pencucian. Pada umumnya, manipulasi eksplisit dari output estimasi akan menjadi negatif untuk proses tersebut. Perkiraan poin cerita bekerja paling baik ketika tim mengawasi bola - Anda memperkirakan kompleksitas relatif dari cerita versus cerita lain, dan selama Anda memiliki informasi historis untuk cerita yang selesai, Anda mungkin akan melihat hal-hal diselesaikan dalam jangka panjang. Inilah tempat di mana kohesi tim memberi manfaat, karena tim pada akhirnya akan menentukan metode dan referensi cerita untuk estimasi cerita.

Deflasi titik cerita bisa menjadi masalah ringan, meskipun, karena kisaran perkiraan titik Anda dikompresi, Anda mulai kehilangan informasi tentang fine tuning kecepatan, dan bahwa kompresi dapat memiliki efek negatif dalam memperkirakan panjang pengiriman pengiriman rilis jangka panjang. perencanaan (karena Anda akan melipatgandakan kesalahan yang diperkenalkan oleh kompresi semua cerita Anda ke dalam rentang yang sempit). Pada umumnya, Anda ingin hasil peningkatan kecepatan karena keahlian diungkapkan sebagai mengambil poin cerita lebih banyak daripada perkiraan turun. Cara untuk memerangi itu adalah dengan terus-menerus referensi perkiraan selesai sebelumnya dan pastikan Anda selalu memperkirakan kompleksitas. Jangan pernah menyatakan berapa lama Anda berpikir akan terjadi sesuatu, bandingkan saja keseluruhan kesulitan sebuah cerita dibandingkan dengan cerita sebelumnya. Membiarkan' katakanlah Anda memiliki aplikasi yang mendukung platform seluler, dan Anda harus porting ke yang lain. Apakah mirip dengan port sebelumnya? Lebih keras, karena platform memiliki tooling yang lebih buruk? Lebih mudah, karena Anda memiliki debugger yang lebih baik? Itu seharusnya menginformasikan perkiraan Anda, bukan fakta bahwa port ini kemungkinan akan berjalan lebih cepat karena tim Anda semakin mahir dalam memperkirakan. Berkonsentrasi pada kompleksitas harus membantu menyelesaikan masalah ini, sejauh ada satu.