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.

Oleh Tim Moovit · Terbit · Diperbarui · 6 menit baca

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

CeremonyKapanPesertaDurasi untuk sprint 2 minggu
Sprint PlanningHari pertama sprintSeluruh Scrum Team1–2 jam
Daily Scrum (daily standup)Setiap hari, jam yang samaDevelopers; lainnya opsional15 menit
Backlog RefinementPertengahan sprintProduct Owner dan Developers30–60 menit
Sprint ReviewHari terakhir sprintScrum Team dan stakeholder45–60 menit
Sprint RetrospectiveSetelah Sprint ReviewSeluruh Scrum Team45–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:

  1. Mengapa sprint ini bernilai? Product Owner mengusulkan bagaimana sprint ini bisa meningkatkan nilai produk. Tim menyepakati Sprint Goal.
  2. Apa yang bisa diselesaikan? Developers memilih item backlog yang mendukung Sprint Goal, dengan mempertimbangkan kapasitas dan pengalaman sprint sebelumnya.
  3. 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):

  1. Product Owner menunjukkan lima sampai delapan item teratas backlog.
  2. Developers bertanya tentang konteks, scope, dan risiko.
  3. Item yang terlalu besar dipecah menjadi bagian yang bisa diselesaikan dalam satu sprint.
  4. Item yang sudah jelas ditandai siap (misalnya dipindah ke status Ready).
  5. 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):

  1. 5 menit: periksa tindak lanjut dari retrospective sebelumnya.
  2. 10 menit: setiap orang menulis catatan secara diam-diam.
  3. 15 menit: kelompokkan catatan dan bahas tema yang paling sering muncul.
  4. 10 menit: pilih satu atau dua perbaikan konkret beserta pemiliknya.
  5. 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

HariCeremony
Senin minggu 1Sprint Planning (pagi), Daily Scrum mulai hari berikutnya
Rabu minggu 2Backlog Refinement
Jumat minggu 2Sprint Review lalu Sprint Retrospective
Senin minggu 3Sprint 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.