Berapa lama pertemuan perencanaan sprint berlangsung?
16
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.
8 jam per 10 hari sprint pasti terdengar terlalu banyak untuk saya. Diskusi yang tidak mengharuskan seluruh tim harus dibawa ke sesi terpisah, hanya untuk anggota yang terlibat.
Péter Török
1
Jadi, Anda merencanakan pertemuan lain alih-alih membahas segala sesuatu dalam perencanaan. Point mencatat.
wleao
Diskusi harus terjadi tentang ide dan rencana yang akan datang sehingga sebagian besar anggota tim memiliki pemahaman dasar dan berbagi tentang mereka. Kriterianya adalah ini: selama pertemuan perencanaan, tidak ada yang harus terkejut karena mendengar hal tertentu untuk pertama kalinya. Kapan pun "kejutan" itu terjadi, sesuaikan dengan meningkatkan jumlah komunikasi yang terjadi sebelum rapat perencanaan berikutnya. (Pengecualian untuk ini adalah pengumuman yang benar-benar inovatif yang berasal dari pemilik proyek.)
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 mungkin merupakan titik awal yang baik, tetapi perlu juga dicatat bahwa Anda perlu menyesuaikan proses dengan proyek, tim, dan organisasi Anda agar bisa bekerja untuk Anda. Hanya karena orang lain beruntung dengan itu tidak berarti itu akan berhasil untuk Anda langsung.
Thomas Owens
6
Namun, jika Anda akan mencoba Scrum, Anda mungkin harus mencobanya berdasarkan pedoman yang ditentukan terlebih dahulu. Lalu, jika sesuatu tidak berfungsi, perbaiki. Jika Anda mengubah aturan bahkan sebelum memulai, Anda mengabaikan bukti empiris yang membuat orang yang merancang Scrum merekomendasikan apa yang mereka rekomendasikan - tanpa bukti empiris untuk menunjukkan bahwa itu adalah hal yang salah untuk Anda.
Matthew Flynn
@MatthewFlynn poin bagus
HA
Di tim saya yang terdiri dari 3 orang, kami biasanya hanya memiliki sprint setengah jam, dan ketika tim berusia 7 tahun, biasanya hanya satu jam untuk sprint selama dua minggu.
Zymus
27
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.
Satu jam tampaknya agak pendek untuk 3 pengembang / sprint 1 minggu. Kemudian lagi, saya baru saja menyelesaikan proyek yang relatif kecil di mana kami melakukan perencanaan sprint mingguan 5 menit. Itu tergantung pada proyek, dan pada kartu, karena kadang-kadang lebih (atau kurang) diskusi diperlukan selama perencanaan sprint.
konfigurator
2
Salah satu ide kunci Scrum, sebagai kerangka Agile, adalah Anda melakukan <i> kotak waktu </i> aktivitas, seperti sprint, rapat perencanaan sprint, dan stand-up / scrum harian. Intinya adalah untuk menjaga hal-hal tetap fokus. Time-boxing tidak berarti Anda tidak dapat mengambil waktu kurang dari yang ditentukan. Hanya saja Anda tidak perlu mengambil lebih banyak, karena itu cenderung membuat orang kehilangan fokus dan juga mengurangi jumlah waktu tim harus benar-benar melakukan pekerjaan.
Matthew Flynn
7
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.
Mengapa tidak memulai proses seperti yang dirancang dan beradaptasi dari sana? Jika Anda memutuskan untuk menggunakan praktik lincah dan belum membentuk bisnis Anda ke arah itu, Anda sudah dalam kesulitan.
JeffO
3
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.
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.
@ GottliebNotschnabel: Terima kasih, itu baru. Saya telah mengganti tautan untuk yang tidak memerlukan login.
Hugo
2
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.
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.
Jawaban:
Menurut Panduan Scrum :
Itu umumnya bekerja untuk saya.
sumber
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.
sumber
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.
sumber
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 ):
Melakukan ini berarti Anda dapat fokus pada perencanaan selama perencanaan, dan tidak butuh waktu seharian dan tim mulai kehilangan fokus dan bosan.
sumber
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.
sumber
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.
sumber
Menurut Panduan Scrum :
sumber