Tidak hanya pertemuan perencanaan sprint kami tidak menyenangkan, mereka benar-benar mengerikan.

Pertemuan itu membosankan, membosankan, dan berlangsung selamanya (sehari, tapi rasanya jauh lebih lama).
Pengembang mengeluh tentang hal itu, dan takut akan rencana yang akan datang.

Rutin kami cukup standar (cerita pengguna dimasukkan ke dalam sprint backlog berdasarkan prioritas >> cerita diambil terpisah dari tugas >> tugas diperkirakan dalam jam >> ulangi), dan saya tidak tahu apa yang kami lakukan salah.

Bagaimana kita bisa membuat pertemuan lebih menyenangkan?

...

Beberapa detail lebih lanjut, sebagai tanggapan atas permintaan untuk informasi lebih lanjut:

Mengapa item backlog tidak dimasukkan dan diprioritaskan sebelum sprint kickoff?

Cerita pengguna memang diprioritaskan; kami tidak tahu berapa lama waktu yang diperlukan sampai kami memecahnya menjadi tugas! Dari jawaban (luar biasa) di sini, saya melihat bahwa mungkin kita seharusnya tidak memperkirakan tugas sama sekali, hanya cerita pengguna. Alasan kami memperkirakan tugas (dan bukan cerita) adalah karena kami telah mendapatkan perkiraan cerita yang sangat salah - tapi saya kira itu adalah subjek untuk pertanyaan yang sama sekali berbeda.

Mengapa pengembang mengeluh?

1. Rapatnya panjang.

2. Rapat itu monoton. Kisah demi kisah, tugas demi tugas, berjuang (ya, berjuang) untuk memperkirakan berapa lama waktu yang dibutuhkan dan apa yang terlibat.

3. Memperkirakan tugas-tugas membuat estimasi cerita-pengguna tampak tidak berguna.

4. Semakin lama pertemuan, semakin sedikit fokus di ruangan itu. Rekan yang kurang fokus adalah, semakin lama pertemuan berlangsung. Spiral-rekursif berkembang. Kami telah mempertimbangkan untuk membagi rapat menjadi dua hari untuk membuat orang tetap fokus, tetapi pengembang tidak mau mendengarnya. Perencanaan satu hari sudah cukup buruk; sekarang kita akan memiliki dua ?!

Bagian dari masalah kami adalah kami melakukan perincian yang sangat kecil (untuk mendapatkan estimasi yang lebih akurat). Tetapi ketika kita memperkirakan secara kasar, kita jauh dari sasaran!

Untuk meringkas pertanyaan:

• Apa yang kita lakukan salah?

• Apa cara tambahan yang ada untuk membuat rapat umumnya lebih menyenangkan?

Jadikan estimasi lebih mudah

Hancurkan perencanaan sprint Anda.

Apakah Anda perlu memperkirakan tugas individu? Saya telah melakukan perencanaan sprint dua cara:

1. Cerita diperkirakan dalam poin cerita dan kemudian tugas diperkirakan dalam hitungan jam
2. Cerita-cerita diestimasi dalam poin cerita dan tugas-tugas jatuh begitu saja tanpa perkiraan

Dari keduanya, saya lebih suka opsi kedua. Saya menemukan bahwa tidak memperkirakan tugas memberikan lebih banyak kebebasan kepada pengembang untuk mengatasi perubahan. Jika suatu tugas tidak lagi masuk akal (berapa kali Anda mengetahui bahwa suatu tugas tidak berlaku atau sudah dilakukan dalam sprint sebelumnya) Anda cukup membuangnya tanpa penalti, atau Anda mungkin harus mengubah tugas saat ini menjadi sesuatu yang baru, mungkin memecahnya. Anda benar-benar berlebihan jika memperkirakan keduanya, karena jumlah tugas harus mewakili poin cerita dan sebaliknya. Apa nilai yang Anda dapatkan dari hal ini selain mengetahui berapa banyak waktu yang dibutuhkan untuk tugas individu? Jika Anda menemukan diri Anda dengan ukuran tugas yang benar-benar cukup bervariasi untuk membuat perbedaan, saya sarankan memecah tugas-tugas tersebut menjadi potongan yang lebih kecil dan lebih homogen.

Dengan melakukan ini, Anda dapat menghemat waktu yang Anda habiskan dalam perencanaan sprint . Cerita diperkirakan selama perencanaan sprint, dan ketika Anda memulai sprint Anda dapat meletakkan semua tugas yang dapat Anda pikirkan yang membentuk cerita itu. Jelas jika ada poin yang Anda temui dalam memperkirakan cerita yang Anda tahu harus ditangani dalam suatu tugas, Anda dapat menambahkan itu ke dalam informasi cerita dan menempatkannya sebagai tugas.

Perkirakan dalam unit Ideal

Poin cerita dimaksudkan untuk berada dalam unit yang ideal seperti jam kerja yang ideal atau hari kerja yang ideal. Ini berarti bahwa mengingat hari yang sempurna setiap hari, di mana Anda tidak memiliki gangguan, tidak ada pertemuan, dan semuanya berjalan sesuai rencana, Anda bisa menyelesaikan tugas dalam X hari. Sekarang semua orang tahu bahwa ini tidak benar, tetapi hal yang menakjubkan tentang statistik adalah tidak harus demikian.

Yang saya maksud dengan ini adalah bahwa setelah beberapa saat memperkirakan ini di hari-hari ideal, Anda menyadari bahwa mungkin dibutuhkan tambahan 25% dari waktu yang Anda perkirakan rata-rata untuk menyelesaikan sebuah cerita. Katakanlah Anda telah memperkirakan 4 hari kerja yang ideal, dan sebaliknya Anda butuh 5. Seiring waktu, Anda melacaknya dan kemudian Anda memiliki gagasan kasar tentang konversi dari hari ideal ke hari nyata. Naluri pertama Anda adalah mencoba dan menggantinya dengan memperkirakan secara berlebihan, dan Anda mungkin salah. Hal utama di sini adalah tetap konsisten. Dengan begitu, rata-rata jangka panjang Anda tetap sama. Tentu kadang-kadang, itu akan di bawah dan kadang-kadang akan berakhir, tetapi semakin banyak Anda memperkirakan, semakin baik Anda. Jika Anda masih menemukannya tidak bisa mendapatkan perkiraan yang layak, mungkin itu berarti Anda tidak cukup tahu tentang cerita untuk memperkirakannya dengan benar.

Bicara tentang ceritanya

Ketika Anda memperkirakan, setiap orang harus memiliki gagasan kasar tentang apa yang perlu dilakukan, dari awal hingga akhir, tentang apa yang diperlukan untuk menyelesaikan cerita ini. Anda tidak perlu tahu setiap detail, tetapi cukup sehingga Anda berpikir Anda sendiri, bisa melakukan cerita. Jika Anda tidak memiliki tingkat kepercayaan itu, Anda mungkin tidak boleh memperkirakannya. Jika Anda mengatakan "Yah, cerita ini terlalu besar untuk kita ketahui sebagian besar detailnya" maka itu merupakan indikasi bahwa cerita itu terlalu besar, dan harus dipecah. Cerita, setidaknya dalam pengalaman saya, cukup kecil sehingga satu orang, jika perlu, dapat mengerjakannya sendiri dan menyelesaikannya dalam satu atau dua minggu.

Ini juga akan membantu menyelesaikan poin kedua Anda di edit, yang terlalu banyak perkiraan . Alih-alih memperkirakan setiap tugas untuk setiap cerita, Anda cukup memperkirakan cerita secara keseluruhan, yang seharusnya membantu menghilangkan banyak dari estimasi tersebut. Sedangkan untuk membuat pertemuan kurang monoton, saya akan menyarankan perencanaan poker, yang dapat Anda lihat informasi lebih lanjut tentang di atas.

Jadikan perencanaan lebih menarik

Perkirakan menggunakan Poker Perencanaan

Sejauh membuat estimasi lebih menyenangkan, apakah Anda sudah mencoba merencanakan poker ? Itulah cara saya selalu melakukan perencanaan untuk semua sprint saya di banyak tim, dan ini adalah cara yang baik untuk membuat semua orang terlibat, karena setiap orang setidaknya harus memilih SESUATU. Ada juga banyak kesenangan yang terlibat ketika semua orang di tim mengambil 3, dan seseorang meletakkan 20 dan harus menjelaskan diri mereka sendiri, atau ketika semua orang di tim menurunkan 5 tetapi manajer meletakkan 8 (siapa yang akan berdebat dengan bos ketika dia ingin memberi Anda lebih banyak waktu!).

Untuk melakukan ini, yang Anda butuhkan adalah beberapa kartu poker perencanaan , yang sering kita buat di sisi belakang kartu indeks, atau menggunakan kartu bermain normal dengan nilai-nilai yang melekat pada kartu wajah. Tidak ada yang mewah, dan itu membuat semua orang fokus. Ingatlah bahwa mencoba melakukan tugas apa pun sepanjang hari (termasuk perencanaan poker) akan mengurangi produktivitas. Banyak set kartu datang dengan kartu kopi karena suatu alasan; jika seseorang merasa lelah, beri tim istirahat untuk mengisi ulang dan mengambilnya ketika semua orang segar!

Sebagai alternatif untuk kartu fisik , Anda juga dapat melihat kartu elektronik . Manfaat nyata di sini adalah pelacakan hasil secara otomatis, melacak cerita pengguna untuk diperkirakan dan memungkinkan semua orang untuk menunjukkan kartu mereka sekaligus untuk menghindari "kecurangan" (di mana satu orang diperkirakan dipengaruhi oleh orang lain karena dapat melihat kartu mereka). Tentunya ini mengharuskan setiap orang memiliki komputer dan kemampuan untuk fokus pada tugas yang dihadapi, jadi gunakan sesuai kehendak Anda sendiri.

1. Mengapa item backlog tidak dimasukkan dan diprioritaskan sebelum sprint kickoff? Membuang waktu pengembang tidak menyenangkan. Biarkan pemimpin tim Anda bekerja dengan pemilik produk dan manajer proyek beberapa hari sebelumnya untuk memprioritaskan hal-hal. Ini berlaku untuk perencanaan yang ada di setiap tim sprint juga.

2. Mengapa perlu satu hari untuk memecahkan masalah menjadi tugas? Jika Anda memiliki tim berukuran sedang (2-4 pengembang, .5-1.5 QA orang per pengembang, 1-2 misc) maka Anda harus memiliki 2-4 cerita pengguna sprint ini. Luangkan 30 menit atau lebih dengan persyaratan klarifikasi pemilik produk, kemudian 30 menit atau lebih untuk ~ 8 jam tugas. Jangan masukkan tugas selama rapat. Cukup sepakati sebagai satu tim tugas apa yang cukup bagi orang waras untuk memahaminya, siapa yang bertanggung jawab atas mereka, dan tentang berapa lama mereka harus melakukannya. Setuju bahwa "berapa lama mereka harus mengambil (termasuk pengujian)" cocok dengan nyaman dalam sprint.

3. Jika tidak hanya memecah tugas menjadi tugas, apa lagi yang Anda lakukan? Tentu, retrospektif bisa memakan waktu 30-60 menit, tetapi akan lebih pendek saat tim masuk ke jalur.

Jadi dalam ringkasan - berhenti membuang-buang waktu orang dan mereka akan takut pertemuan itu sedikit kurang. Di luar itu, kesenangan dan kawan-kawan dalam tim bukanlah sesuatu yang bisa Anda tangani dalam rapat. Pergi makan siang bersama, bercanda, bergaul dengan orang-orang untuk memiliki kepribadian yang lebih baik, memiliki kontes berkumis yang semakin bertambah ... begitu semangat meningkat, orang-orang secara alami akan membuat rapat perencanaan lari lebih ringan.

Perencanaan adalah salah satu area scrum di mana tim memiliki banyak fleksibilitas. Cobalah sesuatu yang baru setiap sprint sampai Anda menemukan sesuatu yang bekerja untuk tim Anda.

Beberapa ide sukses yang telah saya coba secara pribadi, atau dengar dari tim lain:

• Lakukan pembuatan dan prioritas cerita pengguna tanpa seluruh tim. Pemilik produk dan / atau master scrum dapat menangani banyak pekerjaan yang sibuk dan biarkan tim mengubahnya.
• Buat jaminan simpanan Anda secara signifikan lebih lama dari satu sprint. Diperlukan waktu cukup lama untuk membangunnya, tetapi jika simpanan Anda cukup lama, rapat perencanaan dikurangi hingga membuat sedikit penyesuaian atau mengatasi perkembangan bisnis baru-baru ini.
• Buat rapat estimasi terpisah dari perencanaan sprint. Jika orang berpikir pertemuan itu terlalu lama, tidak ada alasan untuk tidak memecahnya.
• Secara khusus rencana masuk ke dalam agenda. Ini berguna jika Anda sering membuang waktu menunggu satu atau dua anggota tim untuk kembali.
• Berhentilah di tengah-tengah rapat dan tetapkan semua orang untuk mengerjakan satu atau dua kisah pengguna, lalu bertemu kembali bersama untuk melaporkan dan mendapatkan konsensus.
• Pastikan rapat perencanaan Anda tentang apa yang harus dilakukan, bukan bagaimana melakukannya. Insinyur mudah jatuh ke dalam yang terakhir. Jika perlu, siapkan rapat desain terpisah tempat Anda membahas caranya.
• Pisahkan cerita Anda menjadi investigasi dan implementasi. Rapat perencanaan sering kali terlalu lama ketika anggota tim tahu terlalu sedikit tentang apa yang akan mereka kerjakan, dan mencoba mencari tahu selama pertemuan.
  Misalnya, Anda perlu berintegrasi dengan API yang tidak dimiliki oleh tim Anda. Daripada mencoba membuat perkiraan dan tugas selama rapat perencanaan tentang sesuatu yang tidak Anda ketahui, buat satu cerita investigasi untuk mempelajari API, lakukan aplikasi "halo dunia" yang sederhana, dan ajarkan itu kepada tim. Maka Anda akan diperlengkapi untuk merencanakan pekerjaan yang sebenarnya.
• Pantau terus selama pertemuan Anda tentang masalah tertentu. Bukan hanya "perencanaan itu membosankan," tetapi tingkat detail seperti, "kita menghabiskan banyak waktu berbicara tentang persyaratan yang tidak jelas, dan sepertinya tidak ada yang tahu jawaban yang tepat." Kemudian diskusikan masalah-masalah spesifik dalam retrospektif dan curah pendapat Anda untuk solusi spesifik. Hancurkan masalah Anda sampai potongan mudah dipecahkan.

Kami memegang perencanaan sprint dan retrospektif kami pada saat bersamaan, dan hampir selalu selesai dalam 90 menit, tetapi kami adalah salah satu tim yang lebih cepat. Kami melakukan perencanaan jangka panjang perusahaan besar-lebar setiap 5 sprint yang memakan waktu 4-6 jam. Setiap tim berbeda, tentu saja, tetapi jika Anda menghabiskan sepanjang hari setiap sprint, ada banyak ruang untuk perbaikan.

Sesi perencanaan Anda terlalu lama!

Berdasarkan pengalaman saya, rapat perencanaan sprint seharusnya memakan waktu tidak lebih dari 2 jam per minggu sedang direncanakan (mis. Sprint 2 minggu paling banyak menghabiskan waktu 1/2 hari), tetapi yang sukses harus lebih pendek dari itu (setengahnya).

Dalam kasus khusus Anda: mengapa Anda memperkirakan tugas? Anda harus memperkirakan hanya cerita selama perencanaan. Tugas dapat diperkirakan kemudian oleh pemilik tugas tertentu .

Cara yang bekerja untuk saya:

• Intro cepat ke sprint oleh PO
• Estimasi kapasitas sprint
• Cerita mengalir ke bawah dan merencanakan poker (kotak waktu pada 5/10 menit per cerita) sampai ada cukup banyak hal yang diperkirakan untuk menutupi sprint
• Komitmen / perkiraan resmi oleh tim

Kemudian, secara paralel / berpasangan / mengatur diri sendiri di meja kami, penugasan dan estimasi tugas.

Di pekerjaan saya sebelumnya, seluruh hari pertama setiap sprint (kami menyebutnya iterasi di sana) diambil dengan:

• Retrospektif. Kami mulai melakukan hal ini pada sore hari terakhir, tetapi kami sering mendapati diri kami melakukan retrospeksi tentang sprint dan kemudian kembali bekerja mengikat ujung longgar dari pekerjaan sprint itu, jadi kami pikir akan lebih baik untuk memastikan pekerjaan ada di belakang kita sebelum merenungkannya. Rasanya logis juga untuk menggabungkan semua overhead rapat proses Scrum sehingga hari-hari lain dapat direncanakan dan dihabiskan dengan istilah yang lebih ideal. Ini biasanya memakan waktu 2 jam.
• Perencanaan Sprint. Tunggakan diperkirakan selama Rapat Perencanaan Milestone (yang bisa menjadi satu hari penuh untuk Devs dan PO), dan telah diprioritaskan oleh PO sebelum awal setiap sprint. Kami menemukan berapa banyak hari pengembang yang kami miliki (akuntansi untuk liburan, vaca, dll), meraih pekerjaan yang kami pikir dapat kami lakukan di atas tumpukan, dan dengan cepat meninjau persyaratan pengguna (sebelumnya diperiksa oleh BA kami) untuk dapatkan pemahaman yang lebih lengkap tentang apa yang dibutuhkan oleh pekerjaan dibandingkan dengan gambaran umum sederhana selama MPM. Ini biasanya memakan waktu 2 jam lagi.
• Perencanaan Tugas. Mengetahui cerita dan kriteria penerimaan, kami membagi masing-masing cerita menjadi tugas-tugas berukuran gigitan yang diperkirakan dalam jam-jam ideal (satu jam dihabiskan hanya berfokus untuk menyelesaikan tugas itu tanpa gangguan atau penghalang jalan). Cara skala poin kami akhirnya dikalibrasi, angka 5 adalah sprint pengembang, jadi angka 1 bisa apa saja hingga dan termasuk dua hari pengembang. Untuk alasan itu, hampir semuanya harus dipecah agar anggota tim dapat menunjukkan kemajuan di papan scrum. Ini adalah blok 2 jam lagi, dengan beberapa memberi dan menerima antara ini dan item berikutnya.
• Garis Besar AAT. PO dan BA kami bukan programmer dan bukan kode. PO bersembunyi di balik kontrak yang menyatakan bahwa mereka akan memberikan persyaratan dalam bentuk templat Word dan akan bekerja dengan BAs untuk memperbaikinya dalam bentuk itu. BA memahami kode, tetapi waktu mereka murni analisis dan pengujian akhir (yang mengharuskan sistem ada, sehingga mereka dapat merekam makro mereka ke Selenium). Jadi, untuk memverifikasi bahwa kode kita akan memenuhi kriteria penerimaan ketika sampai pada hal itu, kita harus menulis AAT kita sendiri yang memodelkan tindakan tes penerimaan "kertas". Kami biasanya melakukan ini dalam kerangka NUnit yang sama dengan yang kami gunakan untuk pengujian unit dan integrasi (kami mencoba FitNesse dan tidak bisa menyerah dengan cukup cepat). Ini adalah sisa hari pertama kami masing-masing berlari dan berlanjut ke hari kedua.

Dalam pekerjaan saya saat ini, kami masih mengadopsi proses Scrum, kami tidak memiliki perencanaan tonggak tim-lebar, dan banyak dari apa yang kami kerjakan tidak memiliki kriteria penerimaan yang ketat. Jadi, perencanaan sprint kami adalah penjelasan tentang apa yang dibutuhkan setiap cerita dan apa yang akan kita sebut dilakukan karena ini adalah komitmen untuk meraih jam ideal X teratas dari pekerjaan. Kami lolos begitu saja - setidaknya untuk saat ini - karena kami adalah tim internal dan masing-masing dari kami bekerja secara pribadi dengan pengguna akhir perangkat lunak kami untuk mengumpulkan persyaratan dan solusi desain. Bahkan kemudian, perencanaan sprint adalah hal yang dilakukan sepanjang pagi setiap Senin, dan sore dihabiskan untuk membersihkan hambatan pribadi untuk dapat memulai pembangunan dengan sungguh-sungguh pada hari Selasa.

Untuk benar-benar menjawab pertanyaan OP daripada membandingkan komentar / jawaban lain yang mengatakan itu tidak perlu waktu lama, ada cara untuk mendekati estimasi Agile, perencanaan sprint dan retrospektif yang sedikit lebih menarik daripada yang mungkin Anda gunakan.

Khusus menangani masalah Anda:

• Rapatnya panjang - Siapkan waktunya. Setiap pertemuan, baik itu retrospektif, perencanaan sprint, rincian tugas, dll, harus memiliki tujuan dan topik diskusi yang pasti, dan harus dibatasi sebanyak mungkin untuk jumlah waktu yang ditentukan. Adalah tugas Scrum Master untuk menjaga pertemuan ini tetap pada topik dan terus bergulir untuk memenuhi tujuan waktu.

• Rapat itu monoton - Akan ada beberapa di antaranya; Anda bekerja dalam potongan seukuran gigitan, satu per satu, sehingga Anda akan melakukan hal yang sama berulang kali. Menjaga agar tim tetap fokus dan terus berupaya mencapai tujuan rapat akan membantu.

  Hal lain yang saya dengar adalah bahwa mungkin rapat perencanaan sprint Anda berusaha untuk mencapai terlalu banyak. Di perusahaan terakhir saya, estimasi cerita dilakukan pada "pertemuan perencanaan tonggak", yang terjadi sekitar seperempat sekali dan menghabiskan waktu seharian. Dalam pertemuan itu, segala sesuatu yang menumpuk di tumpukan yang belum kami perkirakan diperkirakan dalam poin. Jika Anda melakukan estimasi cerita dalam poin, dan kemudian estimasi tugas dalam hitungan jam, Anda tidak ingin melakukannya secara bersamaan (mungkin pada hari yang sama).

• Memperkirakan cerita dalam poin, lalu tugas dalam jam tampaknya berlebihan - Mereka memiliki dua tujuan yang berbeda. Tujuan estimasi cerita adalah untuk memberikan estimasi kasar kompleksitas, yang dapat Anda gunakan untuk mengisi sprint backlog Anda berdasarkan kecepatan masa lalu dan bandwidth yang diharapkan. Tujuan dari estimasi tugas adalah untuk memecah cerita menjadi hal-hal yang memakan waktu satu hari pengembang atau kurang (dan dapat ditugaskan untuk satu pria lajang yang diharapkan menyelesaikan semuanya tepat waktu), dan memastikan Anda belum salah memperkirakan kompleksitas cerita apa pun atau menggigit lebih dari yang Anda bisa lakukan dalam sprint.

  Jika semua cerita Anda memakan waktu satu hari atau kurang, maka itu berlebihan, tetapi tidak semua skala poin dikalibrasi secara merata; pada pekerjaan terakhir saya, 5 adalah dua minggu pengembang (karena pada awalnya kami memiliki banyak epos untuk diperkirakan), yang pada skala linier membuat titik apa pun hingga 2 hari pengembang. Mengingat skala semacam itu, hampir semuanya harus dipecah menjadi tugas. Di perusahaan baru saya, satu poin lebih dekat dengan setengah hari pengembang, jadi 1 atau bahkan 2 jelas merupakan tugasnya sendiri, dan 3-8 samar-samar dalam hal memaksa tim untuk memecahnya menjadi tugas.

• Ada lingkaran setan yang membutuhkan waktu lebih lama membuat orang kurang fokus sehingga butuh waktu lebih lama - Susun kotak waktu Anda. Beristirahatlah, sama seperti Anda seharusnya ketika coding. Setiap 30 menit, ambil 5 menit untuk meregangkan kaki, berkumpul kembali, dll. Anda bisa melakukannya sepuluh menit setiap jam, tetapi jangan terlalu banyak mendorong waktu rapat. Orang-orang Anda mungkin kelaparan, atau membutuhkan lebih banyak kopi, atau istirahat di kamar mandi, dll. Jangan menyangkal mereka; jika Anda membuat mereka menghisapnya, Anda akan mendapati pikiran mereka berkeliaran. Selain itu, menjaga diskusi singkat, manis dan to the point akan membantu juga, seperti yang disebutkan sebelumnya.

Pertemuan perencanaan Sprint memiliki 2 bagian:

1. Putuskan apa yang akan dilakukan tim
2. Putuskan bagaimana tim akan melakukannya.

Bagian pertama relatif lurus ke depan - berdasarkan pada jumlah poin cerita yang menurut tim dapat mereka ambil, komitmen untuk menyelesaikan banyak cerita pengguna sesuai urutan prioritas mereka. Selesai.

Bagian kedua adalah apa yang seharusnya dinikmati oleh para pengembang - elaborasi cerita dan perancangan solusi. Tugas jatuh dari itu. Jadi, mintalah pemilik produk, atau UKM apa pun yang ia sediakan menjelaskan kisah yang dipilih. Kemudian minta pengembang mana pun yang ingin mengambilnya, pimpin diskusi desain. Gunakan papan tulis. Bangkit ide di sekitar. Selamat bersenang-senang.

Itu dia, sungguh. Jika pertemuan desain tidak menyenangkan, maka ada sesuatu yang salah.

Ya saya tahu ini adalah pertanyaan lama, tetapi saya punya jawaban baru. : P

Pisahkan rapat.

Kami membagi pertemuan perencanaan Sprint kami menjadi 3 pertemuan mini terpisah

• Perawatan backlog
• Pemilihan cerita
• Rincian tugas

Kami melakukan masing-masing pada hari yang berbeda, tepat setelah Scrum harian kami - segera setelah harian selesai, kami langsung masuk ke aktivitas perencanaan, dan kemudian kami bebas dari pertemuan (yang direncanakan) sisa hari itu.

Jadi ya, kami membuat perencanaan kami: -O

Saya akan membahas lebih detail tentang apa yang terlibat dalam setiap sesi dalam satu detik, tetapi izinkan saya menjelaskan bagaimana kami sampai pada hal ini.

Kami, seperti Anda, memiliki masalah dengan rapat perencanaan Sprint yang sangat mengerikan. Kami memiliki semua elemen yang tepat, tetapi semuanya hanya berlangsung selamanya dan benar-benar menguras mental dan emosional untuk melewati.

Kemudian saya mendapatkan ide ini setelah membaca artikel Business Insider ini di Pivotal's 5 menit setiap hari tentang memecah pertemuan kami menjadi sesi yang lebih pendek dan melakukannya di awal setiap hari.

Saya membawanya dengan tim di retrospektif. Beberapa anggota tim langsung menyukainya, yang lain agak khawatir, tetapi kemudian magang kami menyebutkan beberapa penelitian yang ia baca tentang teknik pomodoro dan mulai melanjutkan tentang hal itu, dan itu benar-benar membantu ide mendapatkan daya tarik.

Jadi kami memutuskan untuk mencobanya.
Kami membagi waktu 2 jam menjadi 3 sesi 25 menit. (ya, itu matematika yang tidak jelas, tetapi semua orang merasa pertemuan kami terlalu panjang dan hanya ingin melakukannya jika kami menghemat waktu).

Dan itu berhasil! Kami telah melakukannya selama sekitar 6 minggu sekarang di dua proyek terpisah (total 6 sprint dua minggu) dan itu membuat perbedaan dunia.
Kami lebih produktif. Kami menghemat banyak waktu.
Kami mendapatkan hasil yang lebih baik. Dan kami tidak lagi takut pertemuan perencanaan kami.

Dan sejujurnya, kotak waktu 25 menit kami cukup longgar - beberapa sesi berjalan sangat cepat, seperti 5-10 menit pada beberapa sesi perawatan kami, dan beberapa berlangsung lama, seperti ketika kami akhirnya mengidentifikasi cerita baru atau harus membagi cerita dan estimasi ulang selama negosiasi. Namun secara keseluruhan, biasanya rata-rata tidak lebih dari 1,5 jam untuk seluruh shebang, dan saya pikir itu sebabnya ia bekerja dengan sangat baik.

Ke detail .....

Perawatan backlog

Cukup sederhana - kami meninjau cerita prioritas utama, berbicara tentang apa yang diperlukan, dan memastikan perkiraan kami baik.

Kami akan menaksir ulang cerita jika diperlukan - seperti misalnya kami memperkirakan sesuatu bulan lalu dan setelah menyadari apa yang sebenarnya terjadi dengan cerita yang serupa, kami mungkin setuju untuk memperkirakan kembali. ( Ngomong- ngomong, kami menggunakan poin cerita tanpa unit , dan kami tidak memperkirakan tugas ).

Juga, jika PO telah menambahkan cerita baru yang menurutnya merupakan prioritas tinggi, inilah saatnya untuk memperkirakannya.

Karena kita tidak melakukan pemilihan Story hingga hari berikutnya, proses ini memberi PO sedikit waktu untuk melakukan penilaian akhir tentang apa yang paling penting untuk dilakukan dalam iterasi berikutnya - dan ini terbukti sangat membantu.

Pertemuan ini cenderung berjalan singkat dengan beberapa PO dan lama dengan yang lain. (secara pribadi, saya pikir ini adalah indikator bau yang bagus tentang bagaimana PO Anda lakukan)

Pemilihan Cerita

Dapatkan Chris Voss Anda , saatnya untuk bernegosiasi.

Pada pertemuan ini, kami mengambil cerita prioritas utama dan menentukan DoD untuk masing-masing. Kami menegosiasikan apa yang akan dilakukan oleh masing-masing - memecah dan menggabungkan cerita sesuai kebutuhan - sampai kita semua dapat menyetujui tujuan Sprint kita.

Kami mendapat banyak manfaat dari memiliki pikiran yang segar dan energi pagi yang baik untuk pertemuan ini - dan mengetahui bahwa kami akan melakukan tugas di lain hari memungkinkan kami untuk menghabiskan waktu yang kami butuhkan untuk benar-benar bernegosiasi dengan baik dan memahami komitmen kami.

Tugas

Oke, jadi saya akan menjadi yang pertama untuk mengatakan, tugas itu saya PALING favorit bagian dari perencanaan dalam pertemuan satu hari tua kami.

Kami hanya tidak pernah mencapai langkah kami dengan ini. Kami mencoba menyimpan tugas sampai akhir pertemuan - tetapi kami semua hanya dikuras saat itu dan itu benar-benar tidak produktif. Kami mencoba mendefinisikan tugas pada saat yang sama dengan DoD kami selama negosiasi kami, tetapi kami menemukan itu terlalu mengganggu dan terlalu rumit - kami akan kelelahan sebelum memilih semua cerita. Juga, sangat sulit untuk terus beralih fokus / berpikir bolak-balik antara memperkirakan, bernegosiasi, pemilihan cerita, dan pembuatan tugas. Kami berjuang, dan itu menyebalkan, dan itu membuat pertemuan kami mengerikan.

Tapi sekarang, dengan mendefinisikan DoD pada satu hari, dan tidak melakukan tugas sampai hari berikutnya, kita tidak kehabisan tenaga, kita selalu berada di mindstate yang benar, dan itu memberi kita sepanjang hari untuk mengasah cerita dan benar-benar pikirkan dan pahami semua tugas sebelum kita mulai.

Ini saja, IMHO, adalah pengubah total permainan.

Menyatukan semuanya.

Jadi, inilah jadwal upacara Sprint kami sekarang:

• Senin - Scrum harian -> Ulasan Sprint
• Selasa - Scrum harian -> Backlog grooming
• Rabu - Scrum harian -> Pemilihan cerita
• Kamis - Scrum harian -> Tugas
• Jumat - Scrum harian -> Retrospektif

Ini bekerja sangat baik untuk kita. Jika Anda mencobanya, saya ingin mendengar apa yang Anda pikirkan.

Kami memiliki sprint mingguan dengan pertemuan satu jam di mana kami membahas sprint sebelumnya, apa yang tersisa untuk dilakukan dan kemudian beralih ke perencanaan minggu mendatang. Semua dalam satu jam.

Ini tentu saja karena kami mengetahui bahwa dalam kasus kami mengikuti scrum terlalu ketat hanya akan membuang waktu terlalu banyak. Itu karena sebagian besar cerita sudah dibahas dengan anggota tim kami ketika pemohon membuat cerita pengguna.

Saya hanya mengatakan bahwa jika tim Anda takut rapat perencanaan, Anda mungkin harus melepaskan beberapa "aturan" scrum.

Pertanyaan ini telah dijawab secara komprehensif, tetapi hanya satu hal yang diperlukan untuk membuatnya bekerja dan menyenangkan.

Berikan kekuatan kepada tim. - yaitu membuat mereka mengerjakan hal-hal yang mereka pikir paling penting.