Apa yang harus dilakukan dengan estimasi cerita yang tidak lengkap?

Saya adalah bagian dari tim pengembangan yang relatif baru untuk Scrum, anggaplah bahwa pada akhir sprint beberapa cerita besar baik in progressatau tidak acceptedoleh PO.

Pertama, apa yang terjadi dengan cerita pengguna itu? Apakah Anda hanya membawa mereka ke sprint berikutnya?

Jika demikian, haruskah mereka diestimasi ulang? Dalam pandangan saya pekerjaan yang tersisa pada cerita pengguna ini bisa minimal atau banyak? Jika tidak, mengapa tidak?

EDIT: Dalam kasus khusus saya, cerita-cerita itu tidak selesai karena hambatan yang panjang beberapa hari, bukan karena meremehkan cerita pengguna. Bagi Anda yang mungkin bisa membantu, kami menggunakanVersionOne

agile scrum ediblecode
sumber

Saya bekerja dengan proses XP, dan bertanya-tanya apa cara terbaik untuk menghadapi situasi seperti ini

chrisbunney

Kegagalan untuk mengidentifikasi hambatan sebagai risiko yang mungkin dan menentukan eksposur risiko RE (dampak * probabilitas) menunjukkan masalah dengan estimasi. Kisah pengguna dengan RE tinggi perlu memiliki buffer biaya dan waktu yang lebih besar yang terkait dengannya untuk mengatasi risiko tersebut, jika mereka berkembang menjadi masalah.

Thomas Owens

gandakan dan tambahkan 32, sama seperti C => F

Paul

Jawaban:

Pertama, apa yang terjadi dengan cerita pengguna itu? Apakah Anda hanya membawa mereka ke sprint berikutnya?

Tergantung. Jika tidak ada cerita lain yang memiliki prioritas lebih tinggi, maka, ya, mereka akan pindah ke sprint berikutnya. Jika cerita lain memiliki prioritas lebih tinggi, maka mereka mungkin akan dipindahkan kembali ke tumpukan produk jika tidak ada cukup ruang dalam sprint untuk mengakomodasi mereka. Ini semua terjadi dalam perencanaan sprint, berdasarkan prioritas yang ditetapkan untuk setiap cerita oleh Pemilik Produk Anda. Karena salah satu tujuan dari metode gesit seperti Scrum adalah untuk memaksimalkan nilai yang disampaikan sekaligus mengurangi waktu, semuanya berujung pada seberapa banyak nilai ditambahkan dengan menyelesaikan cerita-cerita itu.

Terlepas dari apa yang terjadi, Anda masih perlu berjuang untuk produk yang berpotensi dapat dikirim pada akhir sprint. Ini mungkin berarti memutar balik untuk memastikan bahwa produk akhir sprint melewati semua tes dan fitur yang lengkap dapat digunakan sepenuhnya oleh pengguna tanpa masalah yang berarti.

Jika demikian, haruskah mereka diestimasi ulang? Dalam pandangan saya pekerjaan yang tersisa pada cerita pengguna ini bisa minimal atau banyak? Jika tidak, mengapa tidak?

Saya tidak akan menaksir ulang karena, di Scrum, Anda memperkirakan sebuah cerita ketika Anda menerimanya, mulai bekerja, dan tidak memiliki konsep yang sebagian selesai . Cerita 100% selesai, diuji, dan diterima (selesai) atau tidak selesai. Jika tidak ada konsep sebagian selesai, tidak ada cara bagi Anda untuk menentukan berapa banyak pekerjaan yang tersisa pada cerita. Tampaknya saya juga tidak sendirian dalam pemikiran ini . Anda memperkirakan pekerjaan yang menurut Anda bisa Anda lakukan, jadi tinggalkan data ini dan buatlah untuk membahas mengapa perkiraan itu tidak ada dalam postmortem sprint Anda dan cobalah untuk menghindari membuat kesalahan itu untuk sprint mendatang.

Thomas Owens
sumber

Kami hanya pernah mengalami ini sekali, dan itu tidak ada hubungannya dengan perkiraan yang salah, kami memiliki hambatan macam yang mengakibatkan pekerjaan yang dilakukan, tetapi tidak diuji.

ediblecode

@ user1016253 Itu berarti perkiraan Anda memiliki masalah. Perkiraan harus mencakup paparan risiko (dampak * probabilitas = paparan, di mana paparan berdampak pada biaya, waktu, dan kualitas). Karena ada halangan yang terjadi, tetapi estimasi tersebut tidak memperhitungkannya (atau tidak cukup menjelaskannya), ada sesuatu yang diabaikan atau salah penilaian (dampak atau probabilitasnya terlalu rendah, artinya paparannya adalah terlalu rendah, artinya tidak ada sumber daya yang cukup dialokasikan untuk mengidentifikasi dan memperbaiki masalah ketika itu terjadi).

Thomas Owens

@ user1016253 Dan jika Anda mengalami kesulitan dalam memperkirakan dan melihat risiko dan potensi penghalang jalan, mungkin ide yang baik adalah menguraikan cerita, baik menjadi beberapa cerita yang masing-masing masuk ke dalam tumpukan atau sub-cerita untuk digunakan hanya oleh tim pengembang untuk memahami pekerjaan yang perlu dilakukan. Seringkali lebih mudah untuk memperkirakan dan melakukan analisis risiko pada unit kerja yang lebih kecil.

Thomas Owens

@ Thomas Owens: Itu sepertinya bukan cara yang berguna untuk mengelola risiko bagi saya. Secara khusus, peristiwa dengan probabilitas rendah yang tidak menimbulkan bencana adalah paparan yang rendah, dan karenanya bahkan proyek yang dikelola dengan baik dapat terlempar dari jadwal pada kesempatan tertentu. Jika Anda tidak pernah mengambil risiko, Anda akan mencapai sangat sedikit. Tentu saja pelacakan perkiraan tidak perlu menghindari menerima alasan seperti itu, atau Anda akhirnya membuat perkiraan yang hanya valid seperti investasi yang menyebabkan kehancuran hipotek baru-baru ini, dan untuk alasan yang sama

David Thornley

@DavidThornley Ini bukan cara untuk mengelola risiko sama sekali, tetapi titik awal untuk rencana manajemen risiko yang juga akan mencakup strategi deteksi dan mitigasi. Ini adalah teknik yang digunakan untuk memastikan bahwa Anda memiliki cukup uang dan waktu dalam rencana Anda jika risiko berkembang menjadi masalah. Ini dianjurkan oleh Steve McConnell dalam Estimasi Perangkat Lunak dan Karl Wiegers dalam makalah ini . Penting untuk disadari bahwa itu bukan buffer per tugas, tetapi buffer proyek (atau iterasi) harus memunculkan berbagai risiko.

Thomas Owens

Biasanya, tergantung pada master Scrum terpilih untuk memutuskan apa yang akan terjadi dengan tugas-tugas yang telah menyerbu sprint, jelas setelah berkonsultasi dengan anggota tim lainnya dan sponsor proyek / pemilik produk. Di akhir sprint, inilah saatnya untuk meninjau apa prioritasnya. Mungkin saja cerita yang dipermasalahkan memiliki prioritas lebih rendah daripada cerita baru / yang sudah ada dan harus ditempatkan kembali pada pelacak sebagai 'berkelanjutan' atau apa pun label yang digunakan pelacak Anda, yang menunjukkan bahwa cerita ini akan ditindaklanjuti di titik lain. pada waktunya. Sebagai alternatif, cerita itu dapat sepenuhnya ditiadakan. Anda belum menyebutkan pelacak apa yang Anda gunakan, tetapi sebagian besar yang saya lihat memungkinkan Anda untuk membuat cerita 'dihapus' jika itu bukan lagi bagian dari proyek.

Kedua, karena tim Anda baru mengenal Scrum, ini semua adalah bagian dari proses pembelajaran. Anda sekarang telah mengenali bahwa beberapa cerita terlalu besar, sehingga tim Anda akan mengambil lebih banyak waktu untuk memecah cerita. Biasanya tanggung jawab master scrum untuk memastikan ini terjadi. Master Scrum juga perlu berkonsultasi dengan sponsor proyek / pemilik produk dengan cerita yang tidak lengkap untuk mencoba dan memecahnya lebih lanjut atau mendapatkan keputusan akhir tentang menghapus seluruhnya.

Di tim saya, master Scrum baru dipilih setiap 2 minggu (sprint), jadi setiap orang mendapat kesempatan untuk mengelola tugas, mengatur rapat Scrum, dan memastikan semua orang menyerahkan laporan kemajuan. Saya berharap itulah yang terjadi di tim Anda sendiri, ini tentu pengalaman yang bagus.

Planet terpencil
sumber

Nitpick: Keputusan apa yang harus dilakukan dengan cerita yang tidak lengkap adalah pertanyaan tentang priorat. Jadi saya percaya pemilik produk harus memutuskan ini, bukan master Scrum.

sleske

@sleske - Setuju. Seharusnya aku menjelaskannya dalam jawabanku. Awalnya saya mengatakan scrum master akan berkonsultasi dengan tim, tetapi saya seharusnya menyertakan sponsor / pemilik proyek, yang telah saya koreksi. Terimakasih untuk pemberitahuannya.

Desolate Planet

Jika cerita yang tidak lengkap masih belum selesai pada akhir sprint, Anda tidak dapat benar-benar memecahnya pada saat itu karena itu kemungkinan akan sepenuhnya menumbangkan Definisi Selesai - "Jadi, Anda mengatakan bahwa bagian dari cerita itu Selesai? Tetapi belum ditinjau kode! " Inilah sebabnya mengapa epik-sebagai-satu-cerita mengerikan dan tidak boleh diizinkan menjadi sprint.

Robin Green

@RobinGreen Saya setuju dengan pendapat Anda tentang epos dan saya bukan penggemar mereka. Salah satu hal kunci (sesuatu yang diabaikan oleh banyak orang) adalah nilai retrospektif. Kami baru-baru ini mulai menggunakan papan Agile JIRA dan saya sering menunjukkan kepada tim grafik pembakaran kinerja tim. Kisah-kisah yang tidak lengkap dibahas jika dan ketika itu terjadi dan segera dimasukkan kembali ke dalam simpanan. Dalam retrospektif, kita melihat mengapa cerita itu tidak lengkap. Kekurangan sumber daya? Kurang pengetahuan? atau mungkin kombinasi longgar keduanya.

Desolate Planet