Area Fokus: Acara-acara Scrum

Kompetensi: Memahami dan Menjalankan Framework Scrum

Photo by Mathias Jensen on Unsplash

Tulisan ini akan menjelaskan tentang acara-acara (events) dalam Scrum. Ini adalah tulisan pada tingkat perkenalan yang akan menjelaskan cara kerja suatu Sprint, yang adalah juga suatu acara formal dalam Scrum, di mana tim diharapkan dapat berkolaborasi untuk menghasilkan increment yang berkualitas dan layak untuk di-release.

1 Sprint Planning

Sprint Planning dapat dibagi dalam dua bagian. Waktu untuk dua bagian ini dapat disamakan, dengan rehat di antaranya.

Bagian I: Apa yang harus dikerjakan

• Rencanakan nilai yang akan dihantarkan. Tujuan dari suatu Sprint adalah menghasilkan sebagian pekerjaan yang selesai yang bernilai, layak dan siap untuk di-release segera. Nilai adalah tugas utama seorang Prodcut Owner. Product Owner harus menentukan nilai bisnis dan/atau masalah bisnis yang perlu diselesaikan. Increment yang dikerjakan adalah hasil slicing yang disesuaikan dengan nilai. Penyelesaian pekerjaan haruslah jelas, berdasarkan Definition of Done yang disetujui tim. Proses release dapat dilakukan sesegera mungkin, dan perlu segera dijalankan.
• Tim merencanakan PBI (Product Backlog Item) mana yang perlu disertakan untuk menghantar nilai yang terbaik untuk Sprint tersebut. Bukan PBI mana yang terbaik yang dapat menghantarkan nilai, yang terkadang lebih kualitatif. Sedangkan dengan menghantarkan nilai yang terbaik, kita lebih berorientasi pada nilainya dan kuantitatif. Items yang sudah dipilih harus kohesif. Ini dapat dibantu dengan mengorganisir menggunakan Epics.
• Buat Sprint Goal. Sprint Goal yang baik akan mendemonstrasikan fokus dan komitmen, mendukung kolaborasi, dan siap untuk menghadapi perencanaan ulang (re-planning) pekerjaan.

Sebelum masuk ke bagian II, tim bisa mengadakan rehat. Saat yang tepat bagi Product Owner untuk meninggalkan pertemuan ini jika ada keperluan lain.

Bagian II: Bagaimana mengerjakannya

• Bagaimana untuk mencapai tujuan
• Bagaimana pelaksanaan task yang sudah diasosiasikan

Pada bagian ini, tim dapat mendiskusikan User Stories yang lebih kecil dan/atau tugas-tugas (tasks), termasuk mengidentifikasi dan mengurutkan tugas-tugas teknis. Untuk ini, Product Owner tidak harus hadir tapi harus bersedia jika butuh klarifikasi. Release Plan perlu diinformasikan ke semua pihak terkait, terutama jika akan lebih dari satu kali.

Acara ini perlu dihadiri oleh seluruh tim.

Untuk Sprint 2 minggu, direkomendasi Sprint Planning selama kurang lebih 4 jam.

Product Backlog Refinement/Grooming

Sebelum mengadakan Sprint Planning perlu ada persiapan:

• Product Backlog telah dirincikan sampai ke tingkat yang cukup untuk mulai dikembangkan. Ini dapat termasuk estimasi dari tim dan Acceptance Criteria.
• Product Owner telah mengatur Product Backlog. Product Backlog harus diatur sedemikian rupa sehingga dimaksimalkan untuk pekerjaan Sprint demi Sprint. Product Owner perlu mempunyai gambaran kasar bagaimana akan bernegosiasi dengan tim untuk membuat Sprint Goal yang bernilai. Sprint Planning akan menjadi ajang negosiasi dengan tim, sehingga Product Owner perlu punya gambaran prioritas yang tercermin dalam urutan Product Backlog, misalnya dengan metodologi prioritas MoSCoW.
• Tim telah punya gambaran kasar kapasitas mereka. Gambaran ini berdasarkan pengalaman mereka pada Sprints sebelumnya.

Proses persiapan ini sering disebut dengan Product Backlog Refinement atau Grooming. Proses ini bukanlah acara formal dalam Scrum, namun ini adalah kegiatan yang perlu dilakukan oleh tim secara terus-menerus, rutin.

Product Backlog Refinement atau Grooming berfungsi untuk:

• menambahkan rincian pada Product Backlog
• menentukan urutan
• memberikan estimasi pekerjaan

Acara ini dihadiri oleh seluruh tim.

Refinement atau Grooming dapat dilakukan dengan cara:

1. Product Owner akan menampilkan Product Backlog yang ada saat itu
2. Kerjakan mulai dari atas ke bawah, merincikan satu demi satu:

• Uji lalu diskusikan ruang lingkupnya
• Diskusikan Acceptance Criteria
• Berikan estimasi pekerjaan
• Item yang besar dapat dipecah untuk mendapatkan rincian yang sesuai
• Epics dipecah menjadi User Stories

Tetapkan time-box. Pada kesempatan berikut mulai kembali dari paling atas.

Acara ini seharusnya menghabiskan waktu tidak lebih dari 10% dari waktu tim. Dapat dilakukan misalnya sekitar 30 menit per hari, atau 1–2 jam 2 kali seminggu. Kegiatan ini dapat disesuaikan dengan kebutuhan tim asalkan menghasilkan Product Backlog Items yang telah dirincikan tepat waktu.

Saya merekomendasikan tim mempunyai Backlog yang cukup untuk 2 Sprint. Untuk itu, tim dapat menyesuaikan waktu yang diperlukan untuk Refinement. Saya juga merekomendasikan agar tim menyetujui bersama waktu yang disediakan untuk melakukan Refinement.

2 Daily Scrum

Efektifitas Scrum banyak bertumpu pada efektifitas Daily Scrum. Inilah yang mungkin membuat acara ini menjadi acara yang paling populer. Acara ini sering juga disebut dengan Stand-up.

Daily Scrum bukanlah rapat untuk menginformasikan status atau kemajuan masing-masing. Acara ini berfungsi untuk memastikan:

• rencana yang jelas untuk 24 jam ke depan
• bagaimana akan berkolaborasi
• daftar hambatan (impediment) untuk dibantu Scrum Master

Ada beberapa hal penting yang menjadi tujuan dari Daily Scrum dan membantu efektifitasnya:

• Mempromosikan self-organization. Dengan Daily Scrum, kita meningkatkan tanggung jawab (accountability) setiap anggota tim. Kita memberikan ruang untuk anggota tim menentukan bagaimana akan mengerjakan suatu tugas. Kita menyediakan sarana untuk melakukan inspeksi dan adaptasi harian. Suatu sarana untuk melakukan perencanaan ulang, menuju tanggung jawab.
• Memaksimalkan transparansi. Daily Scrum menyediakan sarana untuk inspeksi dan adaptasi yang sering (frequent). Semua harus tahu hal-hal yang baik maupun yang buruk yang terjadi. Ini adalah kesempatan untuk tim beradaptasi berdasarkan empiricism.
• Mencapai outcome yang bernilai. Dalam Sprint, nilai adalah pembimbing kita. Saat Daily Scrum, kita melakukan perencanaan ulang dan adaptasi terhadap rencana untuk mencapai nilai yang terbaik. Ini perlu dilakukan jika ada tambahan tugas ataupun jika ada masalah yang timbul.
• Kolaborasi. Kita membutuhkan semua bekerja dengan selaras. Daily Scrum adalah sesi perencanaan harian yang kolaboratif.

Daily Scrum harus dihadiri oleh Development Team. Setiap anggota tim akan merangkumkan pekerjaannya: apa yang dilakukan kemarin, apa rencana hari ini, dan apa hambatan yang dialami.

Stand-up diadakan setiap hari kerja pada waktu yang sama, untuk memudahkan tim. Pada acara ini, tim bertemu dan merencanakan ada yang mereka akan lakukan untuk terus mendekat ke Sprint Goal. Acara ini tidak boleh lebih dari 15 menit.

Selalu berkolaborasi

Salah satu praktek Agile yang paling penting adalah kolaborasi. Kolaborasi bukan hanya terjadi di Daily Scrum. Tetapi sepanjang hari, bahkan dalam semua hal yang dilakukan tim sepanjang keseluruhan Sprint. Kolaborasi bisa saja dalam bentuk anggota tim yang sudah selesai dengan tugas hariannya membantu yang lain untuk bersama mencapai tujuan harian tim.

Peranti dalam pekerjaan sehari-hari

Task Board dan Burndown Chart adalah 2 peranti (tools) yang dapat membantu dalam pekerjaan sehari-hari. Kedua peranti ini merupakan information radiators yang dapat menyampaikan informasi untuk siapapun di luar tim. Information radiators akan selalu jujur dalam menyampaikan pekerjaan tim. Untuk itu, tim perlu disiplin dalam penyampaian pekerjaan melalui peranti ini.

3 Sprint Review

Sprint Review seharusnya menjadi acara yang paling ditunggu-tunggu oleh tim. Inilah waktunya tim merayakan pekerjaan mereka yang sudah selesai. Sprint Review dapat menginspirasi terhadap percaya diri sembari mengukuhkan keberlanjutan investasi.

Sprint Review adalah waktunya melakukan inspeksi dan adaptasi. Product Owner menjelaskan bagaimana performa produk saat ini, menghimpun feedback langsung dari hadirin, dan menerima pembelajaran untuk peningkatan Product Backlog. Pekerjaan yang tidak diselesaikan akan ditinjau dan estimasi kembali dalam Product Backlog untuk Sprints berikut.

Kita seringkali menyalahgunakan Sprint Review. Sprint Review bukanlah demo satu arah. Sprint Review juga bukanlah waktunya untuk acceptance, seperti UAT (User Acceptance Test). Sprint Review adalah waktunya berkolaborasi.

Sprint Review adalah acara yang dimiliki oleh Product Owner. Sebagai persiapan, Product Backlog sudah tersedia agar dapat dilihat oleh semua hadirin.

Sprint Review dibuka oleh Product Owner, dapat dengan mengingatkan kepada semua visi produk, Release Goals, dan Sprint Goals. Lalu ia akan menyatakan jika Goals tercapai atau tidak. Selanjutnya, Development Team dapat menjelaskan dengan singkat apa saja yang sudah selesai, apa yang baru dalam iterasi ini. Setelah itu, waktunya bagi Stakeholders untuk mencoba produk yang terkini. Sementara mereka mencoba, Development Team dapat menyebar dan mulai mengamati yang dilakukan oleh Stakeholders dan membantu jika dibutuhkan. Jika ada ide yang baik dan dinyatakan penting (urgent), maka Product Owner akan merujuk pada Product Backlog, perlu ditambahkan di mana dan apa yang akan dikeluarkan.

Dengan ini, Sprint Review menjadi suatu sesi Perencanaan Strategis.

4 Sprint Retrospective

Tujuan dari Sprint Retrospective adalah merefleksikan jika tim sudah bekerja seefektif mungkin.

Dalam acara ini, masing-masing anggota tim mendapat suara yang sama. Setiap anggota tim akan menyampaikan apa yang sudah berjalan dengan baik, apa yang belum, dan peningkatan apa yang diperlukan tim. Selain itu, dalam kesempatan ini, dapat dilakukan apresiasi kepada siapa yang berkontribusi menurut tim.

Acara ini dihadiri oleh seluruh tim.

Sprint Retrospective dapat dibuka dengan kata-kata, “Apapun yang kita dapati, kita mengerti dan sangat percaya bahwa masing-masing kita sudah melakukan pekerjaan terbaik yang bisa dilakukan, sesuai dengan apa yang kita ketahui saat itu, keterampilan kita, kemampuan kita, sumber daya yang kita punya, dan situasi saat itu.”

Apakah kita memerlukan Sprint Retrospective? Seringkali ini dianggap acara yang tidak menarik dan tidak ada nilai. Kita semua sudah dewasa, mengapa perlu Retrospective.

Untuk fans olahraga tim, misalnya sepokbola, kita tahu apa yang dilakukan pemain profesional. Mereka berlatih, berolahraga, bertanding, dan menang (juga kalah). Tapi tidak cukup hanya itu. Untuk terus meningkat, mereka harus melihat kembali bagaimana mereka berlatih, bagaimana mereka bertanding. Mereka harus punya tujuan sebagai tim, akan menjadi tim apa, tentunya tim yang profesional.

Apa yang kita lakukan sebagai tim pengembang perangkat lunak? Kita melakukan coding, analisa, pengujian. Hal lain termasuk memantau dan me-maintain produk, merencanakan pembaharuan teknologi lama, dan memikirkan masa depan produk. Bagaimana kita melakukan hal-hal ini? Pertanyaan ini sering membuat kita mulai berpikir. Beberapa hal ini sedang kita lakukan, tapi mungkin kita masih belum puas dengan bagaimana hal ini dikerjakan sekarang. Mengapa? Mungkin kita kurang waktu sehingga kurang perhatian terhadap salah satu hal.

Di sinilah Scrum dapat menolong kita, yaitu melalui Sprint Retrospective. Alur tanya-jawab seperti di atas dapat kita lakukan dalam acara ini.

Perencanaan dalam Scrum

Ada mitos bahwa tidak ada perencanaan dalam Scrum. Sebaliknya, dalam Scrum kita memilih untuk melakukan perencanaan yang lebih efektif yaitu dengan lebih banyak perencanaan. Dalam Scrum, fokusnya adalah pada aktivitas perencanaan, bukan pada rencana itu sendiri. Dalam Scrum, perencanaan dilakukan secara kolaboratif. Setiap acara dalam Scrum sebenarnya adalah suatu bentuk perencanaan.

Sprint Planning, satu-satunya acara yang mengandung kata plan. Pada acara ini, kita merencanakan dan negosiasikan Sprint Goals. Lalu berdasarkan Goals mulai merencanakan Sprint Backlog, yaitu rencana bagaimana Development Team akan mencapai Goals tersebut.

Daily Scrum, adalah perencanaan kolaboratif untuk paling kurang satu hari kerja.

Sprint Review, adalah sesi kolaboratif untuk mengumpulkan feedback sebagai input pada Sprint Planning berikutnya. Dalam acara ini juga, kita mengkaji hasil dari Sprint berdasarkan Sprint Goals, lalu merencanakan kembali bersama Stakeholders arah berikutnya.

Sprint Retrospective, adalah rencana untuk peningkatan.

Dalam Scrum, mereka yang terlibat dalam pekerjaan tersebut adalah mereka yang memiliki dan membuat rencana. Keseluruhan tim perlu bersama-sama membuat rencana, misalnya (dan terutama) Release Plan.

Model perencanaan dalam Scrum dirancang untuk menghilangkan sampah (waste). Perencanaan dibuat lebih ringan agar meminimalisir kita melakukan analisa terhadap pekerjaan yang terlalu di masa depan. Dengan menganalisa terlalu rinci, kita dapat menimbulkan harapan palsu, menghasilkan sampah dengan berusaha terlalu keras mencoba memprediksi masa depan.

Dalam Scrum, perencanaan dilakukan dengan adaptasi berdasarkan feedback. Feedback langsung didapatkan saat pekerjaan sedang dilakukan. Ini dilakukan karena kita sadar akan sulitnya memprediksi dalam proses pengembangan perangkat lunak.

Perencanaan seperti ini diharapkan meningkatkan kepercayaan. Dengan proses yang empiris, kita dapat menuju kegesitan (agility) dalam bisnis untuk mengambil keputusan-keputusan yang sulit dan melakukan pekerjaan dengan profesional.

Scrum Events oleh Amos Ariane

Slide Presentasi: http://bit.ly/2TZsAos

Berikut tips yang salah dalam menyelenggarakan beberapa acara dalam Scrum:

Planning

1. Hilangkan mereka yang tidak sejalan
2. Biarkan Product Owner melakukan seluruh perencanaan
3. Product Owner boleh meninggalkan tim setelah perencanaan

Stand-up

1. Duduklah saat menjalankan Stand-up
2. Waktu dan tempat meeting yang bervariasi
3. Operkan benda yang berat
4. Dengarlah sementara semua orang lain berbicara

Retrospective

1. Identifikasi kambing hitam
2. Retrospective bukanlah dialog
3. Jangan belajar dari Retrospective

Hindarilah hal-hal ini :)

Kesimpulan. Scrum terdiri dari 5 acara: Sprint itu sendiri, Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective. Semua acara ini, bersama dengan Product Backlog Refinement, diadakan dengan tujuan tim dapat berkolaborasi untuk mencapai nilai yang direncanakan dan menghasilkan increment yang berkualitas.

Slide Presentasi: https://speakerdeck.com/alternat0/acara-acara-scrum

Credits:

• Translated to Indonesian based on Scrum Master Learning Path, Understanding and Applying Scrum competency, Scrum Events focus area by scrum.org