Berapa lama pertemuan perencanaan sprint berlangsung?

Dalam pengalaman Anda, berapa lama pertemuan Perencanaan Sprint (Scrum) bertahan? 8 jam? Atau haruskah itu lebih pendek (ringkas) dan diskusi lebih lanjut harus direncanakan sebagai bagian dari sprint? Sprint kami adalah 10 hari.

Menurut Panduan Scrum :

Pertemuan Perencanaan Sprint dikotak waktu hingga delapan jam untuk Sprint satu bulan. Untuk Sprint yang lebih pendek, acara ini proporsional lebih pendek. Misalnya, Sprint dua minggu memiliki Pertemuan Perencanaan Sprint empat jam.

Itu umumnya bekerja untuk saya.

Selama itu perlu bertahan, tidak kurang dan tidak lebih. Ada lagi yang tidak tangkas.

Jika Anda memiliki tim yang terdiri dari 2 - 3 pengembang dan sedang melakukan sprint 1 minggu, apa pun yang lebih dari satu jam mungkin kontra produktif.

Jika Anda memiliki tim yang terdiri dari 15 orang dan 2 minggu sprint yang Anda lihat sepanjang hari, apa pun yang kurang tidak cukup detail.

Dibutuhkan pengalaman untuk melakukannya dengan benar, dan untuk itulah retrospektif, tim memutuskan apa yang terlalu panjang atau terlalu pendek.

Jangan khawatir tentang menyempurnakannya atau berpegang teguh pada apa yang dikatakan beberapa buku, cobalah sesuatu dan perbaiki.

SCRUM adalah tentang memperbaiki proses dalam iterasi sebanyak tentang memperbaiki kode Anda dalam iterasi.

Jangan membentuk bisnis Anda di sekitar proses. Proses ini mendukung bisnis Anda. Saat Anda melakukan proses untuk kepentingannya sendiri, inilah saatnya proses untuk mendapatkan kapak. Untuk itu, tidak ada cara "benar". Rapat hanya berlangsung selama Anda menyelesaikan sesuatu di dalamnya. Jika Anda membutuhkan waktu 30 menit atau 4 jam, selama itu berhasil maka ikutilah. Abaikan apa yang dikatakan buku / blog / pelatih Anda dan lakukan apa yang benar untuk Anda.

Butuh waktu selama yang Anda butuhkan sehingga Anda cukup memilih sehingga tim Anda berpikir bahwa mereka dapat mencapai yang seharusnya dalam sprint. Tapi Anda harus menghabiskan waktu selama sprint (sebelumnya) memperbaiki backlog: memperkirakan dan memperbaiki cerita.

Dari Scrum Primer ( PDF ):

Penyempurnaan Product Backlog

Salah satu pedoman yang kurang dikenal, tetapi berharga, dalam Scrum adalah bahwa lima atau sepuluh persen dari setiap Sprint harus didedikasikan oleh Tim untuk memperbaiki (atau "merawat") Product Backlog. Ini termasuk analisis persyaratan terperinci, memecah item besar menjadi lebih kecil, memperkirakan item baru, dan memperkirakan kembali item yang sudah ada. Scrum diam tentang bagaimana pekerjaan ini dilakukan, tetapi teknik yang sering digunakan adalah lokakarya terfokus di dekat akhir Sprint, sehingga Tim dan Pemilik Produk dapat mendedikasikan diri untuk pekerjaan ini tanpa gangguan. Untuk Sprint dua minggu, lima persen dari durasi menyiratkan bahwa setiap Sprint ada lokakarya Perbaikan Backlog Produk setengah hari. Aktivitas perbaikan ini bukan untuk item yang dipilih untuk Sprint saat ini; itu untuk item untuk masa depan, kemungkinan besar dalam satu atau dua Sprint berikutnya. Dengan praktik ini, Perencanaan Sprint menjadi relatif sederhana karena Pemilik Produk dan Tim Scrum memulai perencanaan dengan serangkaian item yang jelas, dianalisis dengan baik, dan diperkirakan dengan cermat. Sebuah tanda bahwa lokakarya perbaikan ini tidak dilakukan (atau tidak dilakukan dengan baik) adalah bahwa Perencanaan Sprint melibatkan pertanyaan, penemuan, atau kebingungan yang signifikan dan terasa tidak lengkap; pekerjaan perencanaan kemudian sering meluas ke Sprint itu sendiri, yang biasanya tidak diinginkan.

Melakukan ini berarti Anda dapat fokus pada perencanaan selama perencanaan, dan tidak butuh waktu seharian dan tim mulai kehilangan fokus dan bosan.

Di Scrum, ketika bekerja hingga sprint 2 minggu, perencanaan sprint bertema waktu 4 jam, menjadikannya acara setengah hari. Salah satu alasan untuk jumlah waktu yang relatif besar adalah bahwa tim pengembang harus dapat dengan yakin menyetujui bahwa semua barang yang ditarik ke dalam sprint backlog dapat dikirimkan, yang berarti mereka perlu mengetahui detailnya. Bukan hal yang tidak biasa sebagai bagian dari perencanaan sprint bagi tim untuk berhenti dari ruang pertemuan selama periode waktu untuk menyelidiki item lebih lanjut dan memastikan bahwa mereka "Siap" untuk masuk ke dalam sprint backlog. (Ini dapat membantu untuk memikirkan perencanaan sprint sebagai suatu peristiwa, bukan sebuah pertemuan.)

Gunakan "Definisi Siap" dan lamanya waktu yang memungkinkan acara perencanaan sprint untuk memastikan bahwa semua item jaminan yang masuk ke sprint layak dan siap . yaitu Mereka dapat dilakukan (sepenuhnya, sesuai "Definisi Selesai") dalam sprint, dan ada informasi yang cukup bagi tim untuk dapat melakukannya sekarang.
Perhatikan tentu saja bahwa Anda mungkin tidak ingin melakukan ini untuk SEMUA item selama perencanaan sprint, karena itu bisa sangat memakan waktu. Cobalah dan lakukan perawatan backlog secara teratur (dengan perencanaan sprint) di mana Anda dapat menguraikan item backlog, dan perkirakan item yang belum diperkirakan menggunakan poker perencanaan misalnya. (Saya telah menemukan ini bisa menjadi kegiatan yang efektif untuk makan malam lebih banyak dengan tim pengembang, seandainya Anda memiliki kemewahan dari ketersediaan tim Anda pada waktu makan malam!)

Item prioritas tinggi sering dapat ditambahkan ke jaminan simpanan produk oleh pemilik produk sesaat sebelum perencanaan sprint, dan sementara perawatan jaminan simpanan rutin dapat, dan biasanya harus, dilakukan sebelum acara perencanaan sprint, akan selalu ada item baru seperti ini di mana tim perlu menghabiskan waktu untuk mengerjakan perincian dan memperkirakan kerumitan selama acara perencanaan sprint, karenanya mengapa dapat merentang hingga 4 jam untuk sprint 10 hari / 2 minggu.

Jika Anda perlu mengambil diskusi lebih lama dari acara ini, maka Anda mungkin memiliki item simpanan di sprint backlog untuk "memiliki diskusi ini dan itu untuk membangun x", tetapi Anda harus menghindari memasukkan item sprint untuk melakukan apa pun yang Anda akan lakukan tentukan kebutuhan yang dilakukan selama diskusi itu, karena itu bukan item backlog "siap" untuk masuk ke sprint.

Seperti yang dikatakan orang, ada beberapa alasan Anda mungkin ingin mengubah cara Anda menjalankan Scrum jika prosesnya tidak bekerja secara efektif untuk Anda. Scrum, bagaimanapun, adalah kerangka kerja yang sangat dipikirkan dan diuji untuk memulai sehingga saya akan memastikan alasan Anda dibenarkan sebelum mengubah proses.

Dalam Pertemuan Perencanaan Sprint, tim harus menentukan dua set hal:

A) Apa yang akan dikembangkan oleh tim selama Sprint ini

B) Bagaimana itu akan dikembangkan

Rapat ini harus bertanda waktu, hingga dua jam untuk setiap minggu Sprint, dibagi secara merata untuk setiap bagian (bagian A dan Bagian B) dari rapat.

Jadi, untuk Sprint 4 minggu, rapat ini tidak boleh lebih dari 8 jam, hingga 4 jam untuk bagian A dan hingga 4 jam untuk bagian B.

Selama bagian A, tim pengembang harus memperkirakan kecepatan tim yang mereka anggap akan miliki selama Sprint ini. Mereka juga harus memperkirakan cerita pengguna prioritas utama, dan memilih cukup cerita pengguna (yang sudah diperkirakan) ini untuk diselesaikan sesuai dengan perkiraan kecepatan tim mereka sendiri.

Di bagian B, tim pengembang akan membahas bagaimana mengembangkan kisah pengguna yang lebih menantang yang telah dipilih untuk dikembangkan. Kemungkinan besar, tim pengembang tidak akan punya cukup waktu untuk membahas bagaimana mengembangkan semua cerita pengguna yang dipilih, jadi, tim harus memilih cerita pengguna yang paling menantang.

Selama Sprint, tim dev memiliki cukup waktu untuk menyelesaikan diskusi ini.

Menurut Panduan Scrum :

Acara Scrum

Acara yang ditentukan digunakan dalam Scrum untuk menciptakan keteraturan dan untuk meminimalkan kebutuhan pertemuan yang tidak didefinisikan dalam Scrum. Semua acara adalah acara kotak-waktu, sehingga setiap acara memiliki durasi maksimum. Setelah Sprint dimulai, durasinya ditetapkan dan tidak dapat dipersingkat atau diperpanjang. Acara yang tersisa dapat berakhir setiap kali tujuan acara tercapai, memastikan jumlah waktu yang tepat dihabiskan tanpa membiarkan limbah dalam proses.