Framework Scrum: Peran, Event, dan Artefak Dijelaskan (Beserta Contoh)

Kebanyakan orang mempelajari Scrum dengan cara yang salah. Mereka memperlakukannya sebagai daftar pertemuan yang harus dijadwalkan dan peran yang harus ditetapkan, menjalankan beberapa Sprint, lalu bertanya-tanya mengapa tim masih lambat dalam merilis dan Product Backlog tidak pernah menyusut. Framework Scrum bukanlah metodologi yang diimplementasikan sekali lalu dilupakan. Ini adalah loop umpan balik yang Anda adaptasi setiap Sprint, dan perbedaan itu sangat penting.

Scrum sengaja dibuat ringan. Framework ini memberi Anda struktur yang cukup untuk mengangkat masalah dengan cepat dan memperbaikinya sebelum semakin parah. Tim yang benar-benar mendapat nilai dari Scrum adalah mereka yang serius menerapkan prinsip inspect-and-adapt, bukan mereka yang hanya mengganti nama stand-up mereka menjadi "Daily Scrum."

Apa itu framework Scrum?

Scrum adalah framework Agile yang ringan untuk menyampaikan produk kompleks melalui iterasi singkat yang dibatasi waktu yang disebut Sprint. Framework ini tidak menentukan praktik rekayasa atau alat tertentu. Sebaliknya, ia mendefinisikan sekumpulan minimal peran, event, dan artefak yang dirancang untuk menciptakan transparansi, memungkinkan inspeksi yang sering, dan membuat adaptasi menjadi cepat.

Jeff Sutherland dan Ken Schwaber mengembangkan Scrum di awal 1990-an, mengambil konsep dari lean manufacturing dan kontrol proses empiris. Mereka mempresentasikannya untuk pertama kali di konferensi OOPSLA pada tahun 1995. Scrum Guide resmi pertama diterbitkan pada 2010. Versi terbaru, Scrum Guide 2020, menyederhanakan framework lebih jauh, menghapus elemen-elemen yang bersifat preskriptif dan mempertajam fokus pada tiga pilar empirisme: transparansi, inspeksi, dan adaptasi.

Pemikiran Lean mengalir di seluruh framework ini. Tim Scrum menghilangkan pemborosan dengan bekerja dalam siklus pendek, mendapatkan umpan balik nyata atas software yang berfungsi, dan menghentikan pekerjaan yang tidak membawa produk mendekati tujuannya.

Key Facts

• Sutherland dan Schwaber pertama kali mempresentasikan Scrum secara publik di konferensi OOPSLA tahun 1995, memperkenalkan konsep iterasi dibatasi waktu dengan peran yang terdefinisi.
• Scrum Guide 2020 (tersedia di scrumguides.org) adalah sumber kanonik. Guide ini menghapus istilah "Development Team" dan menyederhanakan framework secara signifikan dibandingkan versi-versi sebelumnya.
• Menurut 17th State of Agile Report (Digital.ai, 2023), Scrum tetap menjadi pendekatan Agile yang paling banyak digunakan, dengan 87% tim Agile menggunakan Scrum atau hibrida Scrum.

Siklus Scrum secara visual

Siklus Scrum adalah loop empiris. Dimulai dari Product Backlog, daftar berurutan dari semua yang mungkin dikerjakan tim. Setiap siklus dimulai dengan Sprint Planning, di mana tim memilih item dari Product Backlog dan membuat Sprint Backlog berisi pekerjaan spesifik yang akan mereka selesaikan dalam Sprint mendatang.

Sprint itu sendiri berlangsung selama satu hingga empat minggu. Selama Sprint, tim mengadakan Daily Scrum setiap hari: pertemuan koordinasi 15 menit di mana para Developers memeriksa kemajuan dan merencanakan ulang pekerjaan mereka untuk 24 jam ke depan.

Di akhir Sprint, tim menyampaikan Increment yang berfungsi, sesuatu yang memenuhi Definition of Done dan secara prinsip bisa dirilis. Sprint Review adalah sesi informal di mana tim dan pemangku kepentingan memeriksa Increment dan mendiskusikan langkah selanjutnya. Kemudian datanglah Sprint Retrospective, di mana tim memeriksa dirinya sendiri: bagaimana mereka bekerja, apa yang perlu ditingkatkan, dan apa yang akan dibawa ke Sprint berikutnya.

Lalu siklus berulang. Product Backlog -> Sprint Planning -> Sprint -> Increment -> Review -> Retro -> Product Backlog. Loop itulah frameworknya. Siklus ini singkat agar kesalahan tidak mahal dan pembelajaran berlangsung cepat.

3 peran Scrum (Scrum Team)

Scrum Guide 2020 menghapus konsep sub-tim. Ada satu Scrum Team, tidak ada hierarki, dan tiga akuntabilitas di dalamnya.

Product Owner

Product Owner bertanggung jawab untuk memaksimalkan nilai produk. Mereka memiliki Product Backlog, mulai dari membuatnya, mengurutkannya, hingga memastikan para Developers memahami isinya. Satu batasan penting dari Scrum Guide: Product Owner adalah satu orang, bukan sebuah komite. Keputusan tentang apa yang dibangun harus berasal dari satu suara tunggal.

Dalam praktiknya, Product Owner bekerja di persimpangan strategi bisnis dan pekerjaan pengembangan. Mereka terus-menerus membuat keputusan penilaian: fitur mana yang layak dibangun berikutnya, kebutuhan pengguna mana yang diprioritaskan, item Backlog mana yang dipangkas. Seorang Product Owner yang lemah dan tidak dapat membuat keputusan tersebut dengan cepat menciptakan hambatan yang akan dirasakan seluruh Scrum Team setiap Sprint.

Product Owner bukan perantara. Ketika pemangku kepentingan menginginkan sesuatu, mereka bekerja melalui Product Owner, bukan melewatinya. Jika organisasi tidak menghormati batasan itu, Scrum tidak akan berjalan dengan baik.

Scrum Master

Scrum Master melayani Scrum Team dan organisasi yang lebih luas. Mereka bertanggung jawab atas efektivitas tim: membantu para Developers bekerja sama dengan baik, membantu Product Owner dengan teknik Backlog, menghilangkan hambatan, dan melatih organisasi dalam adopsi Scrum.

Scrum Master bukan manajer proyek. Mereka tidak menugaskan pekerjaan, melacak jam kerja, atau melaporkan output tim kepada eksekutif. Peran mereka lebih mendekati pelatih dan servant-leader. Mereka melindungi tim dari gangguan, memfasilitasi event, dan memberikan penolakan ketika seseorang (termasuk pimpinan senior) mencoba melewati framework dengan cara yang merusak tim.

Kesalahan umum adalah memperlakukan peran Scrum Master sebagai paruh waktu, sesuatu yang ditangani seorang developer di samping pekerjaan Sprint reguler mereka. Cara ini bisa berhasil untuk tim yang sudah berpengalaman, tetapi tim baru yang mengadopsi Scrum untuk pertama kalinya akan mendapat manfaat dari Scrum Master yang berdedikasi yang benar-benar dapat mengamati sistemnya.

Developers

Developers adalah orang-orang yang menciptakan Increment setiap Sprint. Scrum Guide 2020 mengubah nama dari "Development Team" menjadi "Developers" untuk menegaskan bahwa akuntabilitas tersebut dimiliki oleh semua orang yang mengerjakan pekerjaan itu, bukan sub-tim.

Para Developers bersifat lintas fungsi. Scrum Team secara keseluruhan memiliki semua keterampilan yang dibutuhkan untuk menyampaikan Increment produk yang berfungsi. Itu bisa berarti desainer, insinyur, penguji, dan penulis semua berada dalam tim yang sama, tetapi Scrum Guide tidak mewajibkan keahlian tertentu.

Para Developers memiliki Sprint Backlog dan mengelola pekerjaan mereka sendiri. Tidak ada yang di luar Scrum Team yang memberi tahu mereka cara menyelesaikan pekerjaan atau menugaskan tugas kepada individu tertentu. Mereka yang memutuskan cara mengubah item Sprint Backlog menjadi Increment.

5 event Scrum

Setiap event Scrum dibatasi waktu dan memiliki tujuan. Pembatasan waktu bukan hanya soal efisiensi. Ini menciptakan ritme yang dapat diprediksi dan memaksa keputusan. Berikut adalah kelima event beserta durasi maksimum resminya.

Sprint

Sprint adalah wadah bagi semua event Scrum lainnya. Ini adalah iterasi dengan panjang tetap satu bulan atau kurang. Selama Sprint, tidak ada perubahan yang dapat membahayakan tujuan Sprint, ruang lingkup dapat diklarifikasi seiring tim belajar lebih banyak, dan Sprint tidak dibatalkan kecuali tujuan Sprint menjadi usang.

Panjang Sprint yang konsisten menciptakan detak jantung. Tim tahu kapan perencanaan berlangsung, kapan tinjauan dilaksanakan, dan kapan kesempatan pengiriman berikutnya tiba. Sebagian besar tim menjalankan Sprint dua minggu, meskipun panjang yang tepat bergantung pada toleransi risiko, seberapa sering produk berubah, dan seberapa banyak umpan balik yang dibutuhkan tim.

Sprint Planning

Sprint Planning memulai Sprint dan menjawab dua pertanyaan: apa yang dapat disampaikan dalam Sprint ini, dan bagaimana pekerjaan akan dilakukan? Product Owner mempresentasikan bagian teratas Product Backlog, dan tim memilih pekerjaan yang mereka yakini dapat diselesaikan.

Outputnya adalah tujuan Sprint berupa satu objektif yang memberi kohesi pada Sprint, dan Sprint Backlog, item-item spesifik yang dipilih ditambah rencana untuk menyampaikannya.

Batas waktu: hingga 8 jam untuk Sprint satu bulan. Sprint yang lebih pendek menggunakan waktu yang lebih sedikit secara proporsional.

Daily Scrum

Daily Scrum adalah event 15 menit bagi para Developers untuk memeriksa kemajuan menuju tujuan Sprint dan mengadaptasi rencana mereka untuk 24 jam ke depan. Ini bukan laporan status kepada Scrum Master. Ini adalah koordinasi antar Developers.

Scrum Guide 2020 menghapus tiga pertanyaan yang telah ditetapkan (apa yang saya lakukan kemarin, apa yang akan saya lakukan hari ini, adakah hambatan) dan memberikan fleksibilitas kepada tim dalam cara menjalankannya, selama tujuannya terpenuhi. Tujuannya adalah agar para Developers keluar dengan mengetahui apa yang masing-masing mereka kerjakan dan di mana letak hambatannya.

Sprint Review

Sprint Review adalah inspeksi terhadap Increment dan adaptasi terhadap Product Backlog. Scrum Team dan pemangku kepentingan melihat apa yang dicapai, mendiskusikan apa yang berubah di pasar atau bisnis, dan menyepakati langkah selanjutnya.

Ini bukan sekadar demo, meskipun demo sering terjadi di dalamnya. Perbedaannya penting: demo adalah presentasi, Sprint Review adalah sesi kerja. Pemangku kepentingan bukan penonton, mereka adalah peserta.

Batas waktu: hingga 4 jam untuk Sprint satu bulan.

Sprint Retrospective

Sprint Retrospective adalah tempat Scrum Team memeriksa dirinya sendiri. Apa yang berjalan baik, apa yang tidak, dan satu atau dua hal apa yang akan mereka lakukan secara berbeda pada Sprint berikutnya? Outputnya adalah rencana perbaikan konkret yang berkomitmen untuk ditindaklanjuti tim.

Event ini adalah mesin perbaikan berkelanjutan dalam Scrum. Tim yang melewatkan retrospektif atau memperlakukannya sebagai formalitas berhenti berkembang. Nilainya terakumulasi seiring waktu, sehingga tim dengan praktik retrospektif terbaik cenderung menjadi tim dengan kinerja terbaik dalam satu tahun atau lebih.

Batas waktu: hingga 3 jam untuk Sprint satu bulan.

3 artefak Scrum dan komitmennya

Scrum Guide 2020 memasangkan setiap artefak dengan sebuah komitmen, target yang dapat diukur yang memberi artefak arah dan di mana kemajuannya dapat diperiksa.

Product Backlog (komitmen: tujuan produk)

Product Backlog adalah daftar berurutan yang terus berkembang dari semua hal yang mungkin dilakukan untuk meningkatkan produk. Ini tidak pernah lengkap. Item baru ditambahkan, item lama dihapus, dan prioritas berubah seiring tim belajar.

Komitmen untuk Product Backlog adalah tujuan produk: objektif jangka panjang yang sedang dikerjakan Scrum Team. Setiap Sprint seharusnya membawa produk lebih dekat ke tujuan produk, dan Product Backlog ada untuk menggambarkan jalan menuju ke sana.

Product Owner memiliki Product Backlog dan bertanggung jawab atas pengurutan serta kejelasannya.

Sprint Backlog (komitmen: tujuan Sprint)

Sprint Backlog adalah sekumpulan item Product Backlog yang dipilih untuk Sprint, ditambah rencana untuk menyampaikannya, ditambah tujuan Sprint. Ini adalah gambaran real-time dari pekerjaan yang direncanakan para Developers untuk diselesaikan dalam Sprint ini.

Komitmennya adalah tujuan Sprint: satu objektif yang memberi tujuan pada Sprint. Jika pekerjaan baru muncul selama Sprint, para Developers menambahkannya ke Sprint Backlog hanya jika tidak mengancam tujuan Sprint.

Increment (komitmen: Definition of Done)

Sebuah Increment adalah langkah konkret menuju tujuan produk. Setiap Sprint harus menghasilkan setidaknya satu Increment. Increment tersebut harus dapat digunakan dan memenuhi standar tim.

Komitmennya adalah Definition of Done (DoD): pemahaman bersama tentang apa arti "selesai." Jika sebuah item tidak memenuhi Definition of Done, item tersebut bukan bagian dari Increment. DoD menciptakan transparansi dan konsistensi. Ini bukan daftar periksa per item, melainkan standar kualitas yang berlaku untuk semua Increment.

Sekilas pandang: peran + event + artefak

Ke-11 elemen tersebut adalah semua yang ditentukan Scrum. Itulah seluruh frameworknya. Apa pun di luar ke-11 elemen ini adalah praktik pelengkap (seperti test-driven development atau user story mapping) atau tambahan organisasi yang Anda kelola secara terpisah.

Cadence Sprint 2 minggu yang umum

Berikut tampilan Sprint dua minggu standar dalam praktik, hari demi hari.

Hari 1: Sprint Planning. Tim bertemu, meninjau bagian teratas Product Backlog bersama Product Owner, menetapkan tujuan Sprint, dan membangun Sprint Backlog. Untuk Sprint dua minggu, perencanaan biasanya berlangsung 2 hingga 4 jam.

Hari 1 hingga 10: Pengembangan. Setiap hari, termasuk Hari 1, tim mengadakan Daily Scrum 15 menit. Para Developers berkoordinasi, mengangkat hambatan, dan merencanakan ulang sesuai kebutuhan. Scrum Master menghilangkan rintangan. Product Owner tersedia untuk klarifikasi.

Pagi Hari 10: Sprint Review. Tim mempresentasikan Increment kepada pemangku kepentingan, mendapatkan umpan balik, dan memperbarui Product Backlog. Biasanya berlangsung 1 hingga 2 jam untuk Sprint dua minggu.

Siang Hari 10: Sprint Retrospective. Scrum Team melihat ke dalam dirinya. Apa yang berhasil, apa yang tidak, perubahan apa yang akan dicoba pada Sprint berikutnya. Hingga 1,5 jam.

Hari 11: Sprint baru dimulai. Struktur yang sama, cadence yang sama, membawa satu atau dua perbaikan dari retrospektif.

Konsistensi itulah intinya. Ketika setiap Sprint memiliki bentuk yang sama, overhead koordinasi berkurang dan tim dapat fokus pada pekerjaan sebenarnya. Lihat perencanaan proyek untuk cara menghubungkan cadence Sprint ke jadwal proyek yang lebih luas.

Scrum vs Kanban vs Waterfall

Scrum sering dibandingkan dengan Kanban dan metodologi Waterfall tradisional. Perbedaannya lebih dalam dari sekadar apakah Anda memiliki Sprint atau papan.

Ringkasannya: gunakan Scrum saat Anda membangun sesuatu yang kompleks dan persyaratan akan berubah seiring pembelajaran. Gunakan Kanban saat pekerjaan datang secara berkelanjutan dan Anda perlu mengoptimalkan aliran daripada iterasi. Gunakan Waterfall saat ruang lingkupnya tetap, risiko perubahan rendah, dan Anda membutuhkan rencana penuh di awal (umum dalam konstruksi, industri yang diatur ketat, atau kontrak dengan biaya tetap).

Banyak tim menjalankan hibrida Scrum/Kanban: cadence Sprint untuk pekerjaan pengembangan terencana, papan Kanban untuk bug dan permintaan tak terduga. Cara ini tidak masalah, selama tim jelas sistem mana yang mengatur pekerjaan mana.

Untuk alat penjadwalan terstruktur yang melengkapi Scrum, lihat struktur rincian kerja, metode jalur kritis, Gantt chart, dan PERT chart.

Kesalahan umum yang merusak Scrum

Sebagian besar kegagalan Scrum bukan karena kegagalan framework. Melainkan kegagalan implementasi. Berikut yang paling umum:

• Melewatkan Sprint Retrospective. Ini adalah event di mana Scrum memberikan hasil berlipat ganda. Tim yang melewatkannya tetap berada di tingkat disfungsi yang sama tanpa batas waktu. Jika waktu terbatas, persingkat retrospektifnya, tapi jangan hilangkan.
• Memperlakukan Scrum Master sebagai manajer proyek. Menugaskan tugas, melaporkan velocity kepada pimpinan, dan mengelola jadwal adalah fungsi PM. Seorang Scrum Master yang melakukan pekerjaan tersebut tidak menjalankan tugas Scrum Master. Kedua peran pun menjadi lemah.
• Tidak memiliki Product Owner yang nyata. Seorang Product Owner yang tidak dapat membuat keputusan prioritas, membutuhkan persetujuan dari tiga komite, atau mengubah tujuan Sprint di tengah jalan menghancurkan kemampuan tim untuk merencanakan dan menyampaikan.
• Membiarkan pemangku kepentingan melewati Product Owner. Para Developers yang menerima permintaan fitur langsung dari eksekutif atau klien adalah tanda bahwa wewenang Product Owner tidak dihormati. Perbaiki budaya organisasi, bukan frameworknya.
• Menjalankan Sprint tanpa tujuan Sprint. Sprint yang hanya berupa daftar tugas tidak memiliki objektif pemersatu. Tim tidak dapat membuat keputusan pertukaran yang baik saat informasi baru muncul, karena tidak ada yang perlu dilindungi.
• Memperlakukan Scrum sebagai solusi lengkap. Scrum tidak mencakup praktik rekayasa. Tim juga membutuhkan otomasi pengujian, integrasi berkelanjutan, dan standar kualitas yang jelas (Definition of Done) untuk benar-benar merilis Increment yang berfungsi. Tanpa itu, Sprint Review menjadi parade fitur setengah jadi.

Pertanyaan yang sering diajukan

Apakah Scrum sama dengan Agile?

Tidak. Agile adalah seperangkat nilai dan prinsip, yang dijelaskan dalam Agile Manifesto (2001). Scrum adalah satu framework untuk mengimplementasikan prinsip-prinsip tersebut. Anda bisa Agile tanpa menggunakan Scrum, dan Anda bisa menjalankan Scrum dengan buruk sehingga bertentangan dengan nilai-nilai Agile. Anggaplah Agile sebagai filosofi dan Scrum sebagai salah satu cara terstruktur untuk mempraktikkannya. Framework Agile lainnya meliputi Kanban, Extreme Programming (XP), dan SAFe (Scaled Agile Framework).

Bisakah Scrum berjalan tanpa Scrum Master?

Secara teknis, Scrum membutuhkan Scrum Master. Dalam praktiknya, tim yang sudah matang terkadang beroperasi tanpa satu orang yang berdedikasi dengan mendistribusikan tanggung jawab pelatihan dan fasilitasi di antara anggota tim. Tetapi tim yang baru mengenal Scrum biasanya membutuhkan Scrum Master yang aktif melindungi framework, melatih tim, dan menghilangkan hambatan organisasi. Tanpa peran itu, tim cenderung kembali ke kebiasaan lama: stand-up berubah menjadi rapat status, retrospektif dilewatkan, dan Product Owner kehilangan wewenang Backlog mereka.

Berapa lama seharusnya sebuah Sprint?

Scrum Guide 2020 menyatakan satu bulan atau kurang, dengan sebagian besar tim memilih satu hingga empat minggu. Sprint dua minggu adalah yang paling umum dalam praktik. Panjang yang tepat bergantung pada seberapa stabil persyaratannya, seberapa sering tim membutuhkan umpan balik eksternal, dan seberapa banyak overhead perencanaan yang dapat diserap tim. Sprint yang lebih pendek berarti umpan balik lebih cepat tetapi lebih banyak seremonial perencanaan relatif terhadap waktu pengembangan. Sprint yang lebih panjang mengurangi overhead seremonial tetapi menunda umpan balik. Mulailah dengan dua minggu dan sesuaikan berdasarkan apa yang Anda pelajari.

Apa yang dihapus dalam Scrum Guide 2020?

Revisi 2020 menghapus beberapa hal yang telah terakumulasi di versi sebelumnya. Tiga pertanyaan Daily Scrum yang ditetapkan ("apa yang saya lakukan kemarin, apa yang akan saya lakukan hari ini, adakah hambatan?") dihapus demi format yang lebih fleksibel. Istilah "Development Team" diganti dengan "Developers." Konsep Chief Product Owner dan Sprint 0 dihilangkan. Peran Scrum Master sebagai "servant-leader" dirumuskan ulang menjadi "true leader." Guide 2020 juga menambahkan tiga komitmen artefak (tujuan produk, tujuan Sprint, Definition of Done) untuk pertama kalinya sebagai tambahan baru.

Scrum akan terus berkembang. Itulah intinya. Framework itu sendiri mempraktikkan apa yang diajarkannya: periksa, adaptasi, dan rilis versi yang lebih ramping.

Bagi tim yang ingin menggunakan matriks RACI bersamaan dengan peran Scrum mereka, perlu diingat bahwa RACI bekerja dengan baik untuk memetakan hak keputusan di antara pemangku kepentingan, sementara peran Scrum mendefinisikan akuntabilitas dalam tim. Kedua framework saling melengkapi, bukan bertentangan.