Scrum ceremonies: sprint planning, daily standup, review, dan retrospective
Panduan lengkap Scrum ceremonies untuk tim kecil: tujuan, peserta, durasi, dan agenda sprint planning, daily standup, sprint review, retrospective, dan backlog refinement.
Scrum ceremonies adalah pertemuan rutin dalam Scrum yang memberi tim kesempatan untuk merencanakan, memeriksa progres, menunjukkan hasil, dan memperbaiki cara kerja. Scrum Guide menyebutnya events. Istilah “ceremonies” lebih sering dipakai sehari-hari, termasuk di tim Indonesia.
Setiap ceremony punya tujuan yang spesifik. Jika tujuan itu tidak tercapai, ceremony hanya menjadi rapat tambahan. Panduan ini menjelaskan tujuan, peserta, durasi, dan agenda setiap ceremony untuk tim kecil dengan sprint satu atau dua minggu. Jika Anda baru mengenal Scrum, baca dulu apa itu Scrum.
Ringkasan Scrum ceremonies
| Ceremony | Kapan | Peserta | Durasi untuk sprint 2 minggu |
|---|---|---|---|
| Sprint Planning | Hari pertama sprint | Seluruh Scrum Team | 1–2 jam |
| Daily Scrum (daily standup) | Setiap hari, jam yang sama | Developers; lainnya opsional | 15 menit |
| Backlog Refinement | Pertengahan sprint | Product Owner dan Developers | 30–60 menit |
| Sprint Review | Hari terakhir sprint | Scrum Team dan stakeholder | 45–60 menit |
| Sprint Retrospective | Setelah Sprint Review | Seluruh Scrum Team | 45–60 menit |
Durasi di atas adalah perkiraan untuk tim kecil. Scrum Guide menetapkan batas maksimal untuk sprint satu bulan: Sprint Planning 8 jam, Sprint Review 4 jam, dan Retrospective 3 jam. Daily Scrum selalu 15 menit. Untuk sprint yang lebih pendek, durasinya biasanya lebih singkat.
1. Sprint Planning
Tujuan: menyepakati Sprint Goal dan rencana untuk mencapainya.
Sprint Planning menjawab tiga pertanyaan:
- Mengapa sprint ini bernilai? Product Owner mengusulkan bagaimana sprint ini bisa meningkatkan nilai produk. Tim menyepakati Sprint Goal.
- Apa yang bisa diselesaikan? Developers memilih item backlog yang mendukung Sprint Goal, dengan mempertimbangkan kapasitas dan pengalaman sprint sebelumnya.
- Bagaimana pekerjaannya dilakukan? Developers memecah item menjadi task yang bisa diselesaikan dalam satu hari atau kurang.
Agenda contoh (90 menit):
- 10 menit: Product Owner menjelaskan konteks dan usulan tujuan.
- 15 menit: tim menghitung kapasitas, termasuk cuti, support, dan rapat.
- 40 menit: memilih item backlog dan membahas pertanyaan.
- 20 menit: memecah item pertama menjadi task.
- 5 menit: membaca ulang Sprint Goal dan memastikan semua orang setuju.
Tanda berhasil: semua orang bisa menjelaskan Sprint Goal dalam satu kalimat. Contoh lengkap dengan perhitungan kapasitas ada di panduan sprint planning untuk tim kecil.
2. Daily Scrum atau daily standup
Tujuan: memeriksa progres menuju Sprint Goal dan menyesuaikan rencana untuk 24 jam ke depan.
Daily Scrum sering disebut daily standup karena banyak tim melakukannya sambil berdiri agar tetap singkat. Rapat ini untuk Developers, bukan laporan ke atasan.
Banyak tim memakai tiga pertanyaan klasik: apa yang saya selesaikan kemarin, apa yang akan saya kerjakan hari ini, dan apa hambatan saya. Scrum Guide 2020 tidak lagi mewajibkan format ini. Format alternatif yang sering lebih efektif adalah membahas board dari kanan ke kiri: mulai dari task yang paling dekat dengan Done, lalu tanyakan apa yang dibutuhkan untuk menyelesaikannya.
Tips:
- Mulai tepat waktu, di jam yang sama setiap hari.
- Bahas hambatan secara singkat; diskusi detail dilanjutkan setelahnya oleh orang yang terlibat.
- Untuk tim remote, buka board di layar bersama agar semua melihat status yang sama.
- Jika tim tersebar di zona waktu berbeda, daily standup tertulis lewat komentar bisa menjadi alternatif.
Tanda berhasil: tim tahu apakah Sprint Goal masih tercapai dan siapa membantu siapa hari ini.
3. Backlog Refinement
Tujuan: menyiapkan item backlog agar siap dipilih di Sprint Planning berikutnya.
Refinement bukan event resmi dalam Scrum Guide, tetapi merupakan kegiatan rutin yang membuat Sprint Planning jauh lebih singkat. Dalam refinement, tim memperjelas item, menambahkan acceptance criteria, memecah item besar, dan membuat estimasi kasar.
Agenda contoh (45 menit):
- Product Owner menunjukkan lima sampai delapan item teratas backlog.
- Developers bertanya tentang konteks, scope, dan risiko.
- Item yang terlalu besar dipecah menjadi bagian yang bisa diselesaikan dalam satu sprint.
- Item yang sudah jelas ditandai siap (misalnya dipindah ke status Ready).
- Pertanyaan yang belum terjawab dicatat beserta pemiliknya.
Cara menulis item yang jelas ada di panduan menulis task.
4. Sprint Review
Tujuan: memeriksa hasil sprint bersama stakeholder dan menyesuaikan arah produk.
Sprint Review bukan presentasi slide. Tim menunjukkan Increment yang benar-benar berfungsi, lalu stakeholder mencoba dan memberi masukan. Hasil diskusi bisa mengubah urutan Product Backlog.
Agenda contoh (60 menit):
- 5 menit: Product Owner mengingatkan Sprint Goal dan menjelaskan apa yang selesai serta yang belum.
- 25 menit: demo hasil yang memenuhi Definition of Done.
- 20 menit: diskusi umpan balik dan perubahan kondisi bisnis.
- 10 menit: membahas kemungkinan prioritas sprint berikutnya.
Tips: tunjukkan hanya pekerjaan yang benar-benar selesai. Pekerjaan setengah jadi membingungkan stakeholder tentang apa yang bisa dipakai.
5. Sprint Retrospective
Tujuan: memperbaiki kualitas dan efektivitas cara kerja tim.
Retrospective membahas orang, interaksi, proses, alat, dan Definition of Done. Fokusnya bukan mencari siapa yang salah, tetapi apa yang bisa diubah di sprint berikutnya.
Format yang sering dipakai:
- Start / Stop / Continue: apa yang perlu mulai dilakukan, dihentikan, dan dipertahankan.
- Mad / Sad / Glad: membahas perasaan tim terhadap sprint, cocok ketika ada ketegangan.
- 4L (Liked, Learned, Lacked, Longed for): apa yang disukai, dipelajari, kurang, dan diharapkan.
Agenda contoh (45 menit):
- 5 menit: periksa tindak lanjut dari retrospective sebelumnya.
- 10 menit: setiap orang menulis catatan secara diam-diam.
- 15 menit: kelompokkan catatan dan bahas tema yang paling sering muncul.
- 10 menit: pilih satu atau dua perbaikan konkret beserta pemiliknya.
- 5 menit: tutup dengan apresiasi singkat.
Simpan perbaikan sebagai task di sprint berikutnya agar tidak terlupa.
Kesalahan umum dalam Scrum ceremonies
- Ceremony melebihi waktu. Batas waktu memaksa tim fokus pada keputusan penting.
- Daily standup menjadi rapat pemecahan masalah. Catat masalahnya, lalu bahas setelah standup dengan orang yang terlibat saja.
- Sprint Review tanpa stakeholder. Tanpa umpan balik dari luar tim, review hanya menjadi demo internal.
- Retrospective tanpa perubahan. Jika masalah yang sama muncul di setiap retrospective, tindak lanjutnya belum konkret.
- Melewatkan refinement. Akibatnya Sprint Planning berlangsung berjam-jam karena item belum jelas.
Jadwal contoh untuk sprint dua minggu
| Hari | Ceremony |
|---|---|
| Senin minggu 1 | Sprint Planning (pagi), Daily Scrum mulai hari berikutnya |
| Rabu minggu 2 | Backlog Refinement |
| Jumat minggu 2 | Sprint Review lalu Sprint Retrospective |
| Senin minggu 3 | Sprint berikutnya dimulai dengan Sprint Planning |
Total waktu ceremony untuk sprint dua minggu sekitar 6–7 jam per orang, termasuk sepuluh Daily Scrum. Itu sekitar 8% dari waktu kerja dua minggu, dengan imbalan prioritas yang jelas dan masalah yang terlihat lebih awal.
Menjalankan ceremonies dengan Moovit
Buka Sprints di Sprint Planning untuk membuat sprint dan memilih task. Gunakan Board saat Daily Scrum agar semua melihat status yang sama. Saat refinement, perjelas task di Backlog dengan deskripsi, checklist, dan acceptance criteria, lalu pindahkan ke Ready. Catat hasil retrospective sebagai task di sprint berikutnya.
Unduh template sprint planning untuk sesi perencanaan pertama, atau buat akun Moovit untuk menjalankan sprint bersama tim.