---

Apa itu Koordinasi dan Perencanaan Banyak Tim? Jawabannya Mungkin Mengejutkan Anda!

Scrum of Scrum

Setelah melihat bab sebelumnya, pertanyaan logis berikutnya mungkin bagaimana mengoordinasikan berbagai Scrum Team agar bekerja sama secara efisien.

Itu pertanyaan wajar, dan kami juga berusaha menjawabnya.

Pertemuan Scrum of Scrum

Pertemuan Scrum of Scrum menyerupai Daily Scrum. Namun, fokusnya bukan pekerjaan setiap anggota, melainkan Scrum Team itu sendiri.

Scrum of Scrums merupakan praktik koordinasi opsional, bukan acara formal Scrum tambahan. Tim dapat memilih batas waktu harian 15 menit; jika konteks memerlukan koordinasi lebih banyak, sesi 30 hingga 60 menit merupakan contoh lain. Tim perlu menginspeksi kegunaan format tersebut.

Contoh Pertanyaan Koordinasi

• Apa yang dilakukan tim kemarin?
• Apa yang direncanakan tim hari ini?
• Adakah hambatan yang menghalangi atau memperlambat kemajuan tim?

Jawaban tentu perlu mencakup cerita pengguna serta ketergantungan yang juga memengaruhi tim lain.

Dalam pola koordinasi historis ini, Chief Scrum Product Owner dan Lead Scrum Master dapat bersama-sama memfasilitasi Scrum of Scrums. Ini sebutan organisasi opsional, bukan akuntabilitas Scrum tambahan. Salah satu dari mereka juga dapat memoderasi pertemuan atau mereka dapat bergiliran menjalankan tugas tersebut.

Pertemuan Sprint Review Bersama

Sprint Review bersama seluruh Scrum Team tidak wajib, tetapi dapat sangat bermanfaat. Tim tetap harus memenuhi tujuan Sprint Review. Tim pada satu produk menginspeksi hasil terintegrasi bersama pemangku kepentingan; sesi lokal terpisah bukan duplikasi acara yang diwajibkan.

Pesertanya adalah perwakilan Scrum Team serta Product Owner yang bertanggung gugat atas produk bersama. Pemangku kepentingan juga berpartisipasi menginspeksi hasil.

Scrum Team juga dapat menggilir perwakilan sesuai preferensinya. Fasilitator yang ditunjuk, seperti Lead Scrum Master opsional dalam contoh ini, dapat membantu efektivitas Review bersama.

Sprint Review bersama memungkinkan seluruh Scrum Team memperagakan Increment Produk Siap Kirim kepada Product Owner yang bertanggung gugat, kontak produk pendukung, serta pemangku kepentingan relevan.

Dengan demikian, Sprint Review bersama memenuhi dua tujuan:

1. Seluruh Scrum Team selaras mengenai status keseluruhan proyek saat ini.
2. Seluruh Scrum Team memperoleh umpan balik pekerjaannya dan dapat memperhitungkannya dalam Sprint Planning mendatang.

Sprint Retrospective Bersama

Seperti Sprint Review bersama, Sprint Retrospective bersama tidak wajib, tetapi dapat sangat bermanfaat.

Sprint Retrospective bersama tidak menggantikan retrospektif yang harus diadakan setiap Scrum Team.

Pesertanya adalah perwakilan Scrum Team. Setiap tim dapat menggilir perwakilan sesuai pertimbangannya.

Sprint Retrospective bersama dapat difasilitasi koordinator yang ditunjuk, seperti Lead Scrum Master opsional dalam contoh ini. Pertemuan bertujuan menemukan serta menindaklanjuti peluang perbaikan penggunaan Kerangka Kerja Scrum oleh organisasi proyek Scrum yang lebih besar.

Seluruh masalah yang memerlukan perhatian serta kolaborasi beberapa Scrum Team (Pelajari lebih lanjut tentang Beberapa Scrum Team) untuk diselesaikan perlu disoroti dalam pertemuan ini. Jalur penyelesaiannya harus direncanakan, dijadwalkan, dan ditindaklanjuti.

Perencanaan Banyak Tim: Scrum Product Backlog Global

Ketika beberapa tim mengerjakan produk yang sama, mereka berbagi satu Product Goal dan Product Backlog di bawah satu Product Owner yang bertanggung gugat. Pelajaran ini menyebut tampilan bersama tersebut Scrum Product Backlog Global. Kontak produk pendukung serta tim dapat membantu refinement isinya, tetapi akuntabilitas tetap pada Product Owner tersebut.

Backlog Khusus Tim

Bila diperlukan, cerita pengguna Scrum Product Backlog Global dapat dipecah menjadi cerita yang lebih khusus bagi tim.

Detail ini dapat dipelihara dalam tampilan kerja khusus tim dan, setelah dipilih, Sprint Backlog setiap tim. Tampilan merujuk kembali pada Product Backlog bersama, bukan menjadi Product Backlog yang diprioritaskan secara mandiri bagi produk yang sama. Rujukan ini membantu Scrum Team melihat peran cerita penggunanya dalam gambaran besar proyek serta jenis nilai klien yang disampaikan.

Penjadwalan Sprint

Dalam proyek Scrum terdistribusi, terdapat dua pilihan penyelarasan pekerjaan berbagai Scrum Team.

• Sprint Sinkron
• Sprint Asinkron

Pilihan pertama adalah Sprint Sinkron. Semua tim memulai serta mengakhiri Sprint pada hari yang sama.

Sprint Sinkron biasanya lebih disukai karena memudahkan komunikasi serta koordinasi Scrum Team.

Sprint Sinkron

Pilihan lain adalah Sprint Asinkron. Sprint tidak dimulai dan diakhiri pada hari yang sama. Keunggulan Sprint Asinkron adalah seluruh Ritual Scrum setiap tim tidak harus berlangsung pada hari sama. Ini memungkinkan Product Owner serta kontak koordinasi pendukung mengikuti Sprint Planning, Sprint Review, dan Sprint Retrospective tim lain serta mendukungnya ketika diminta.

Ketika satu tim menyediakan layanan bagi tim lain, Sprint asinkron memberi keunggulan tambahan.

Sprint Asinkron

Skenario pada sketsa di atas memperjelasnya: Pekerjaan Tim-A (Tim Pemasok) perlu diintegrasikan ke hasil Tim-B (Tim Utama). Dengan Sprint Asinkron, Tim-A dapat menutup Sprint sebelum Tim-B. Tim-B (Tim Utama) kemudian mengambil hasil Tim-A (Tim Pemasok) dan mengintegrasikannya sebelum menutup Sprint sendiri.

Estimasi Upaya

Tim dapat memilih konvensi ukuran bersama, seperti poin bergaya Fibonacci atau ukuran kaus, bila membantu perencanaan bersama. Scrum tidak mewajibkannya, dan poin atau Kecepatan satu tim tidak otomatis dapat dibandingkan dengan tim lain.

Bila konvensi bersama berguna, terapkan secara konsisten dalam Product Backlog bersama sambil menjaga tanggung jawab Developers atas penentuan ukuran.

Estimasi Tim Komponen perlu perhatian khusus. Tim ini biasanya menyediakan layanan bagi cerita pengguna Tim Fitur. Karena itu, mereka perlu memperoleh dukungan serta penjelasan yang diperlukan selama Sprint Planning dan estimasinya sendiri.