Kanban vs Scrum: perbedaan dan cara memilih untuk tim kecil

Perbandingan Kanban dan Scrum: ritme kerja, peran, board, metrik, dan perubahan prioritas. Termasuk panduan memilih dan pendekatan Scrumban.

Oleh Tim Moovit · Terbit · Diperbarui · 5 menit baca

Kanban dan Scrum adalah dua framework agile yang paling sering dipakai tim kecil. Keduanya memakai board, mendorong transparansi, dan membantu tim menyelesaikan pekerjaan dengan lebih terarah. Perbedaannya ada pada ritme: Scrum bekerja dalam sprint dengan durasi tetap, sedangkan Kanban mengalirkan pekerjaan secara kontinu.

Panduan ini membandingkan keduanya secara praktis dan membantu Anda memilih berdasarkan jenis pekerjaan tim, bukan tren.

Ringkasan perbedaan

AspekScrumKanban
RitmeSprint dengan durasi tetap, 1–4 mingguAlur kontinu tanpa periode tetap
PeranProduct Owner, Scrum Master, DevelopersTidak ada peran wajib
PerencanaanDi awal setiap sprintSaat ada kapasitas, sesuai kebutuhan
Perubahan prioritasIdealnya di antara sprintBisa kapan saja untuk pekerjaan yang belum dimulai
Batas pekerjaanJumlah pekerjaan per sprintBatas WIP per status
BoardDireset atau dibersihkan setiap sprintTerus berjalan
EventPlanning, Daily Scrum, Review, RetrospectiveTidak wajib; banyak tim memakai review rutin
Metrik umumPencapaian Sprint Goal, velocityCycle time, lead time, throughput

Cara kerja Scrum secara singkat

Scrum membagi waktu menjadi sprint. Di awal sprint, tim menyepakati Sprint Goal dan memilih pekerjaan. Selama sprint, tim fokus pada pekerjaan itu. Di akhir sprint, hasil ditunjukkan ke stakeholder dan tim mengevaluasi cara kerjanya.

Scrum memberi struktur yang jelas: peran, artifact, dan lima event. Struktur ini membantu tim yang baru belajar agile, tetapi juga menuntut disiplin. Penjelasan lengkap ada di apa itu Scrum dan Scrum ceremonies.

Cara kerja Kanban secara singkat

Kanban berasal dari sistem produksi Toyota dan kemudian diadaptasi untuk pekerjaan pengetahuan. Kanban tidak mengatur peran atau periode. Fokusnya pada aliran pekerjaan dengan beberapa praktik inti:

  • Visualisasikan alur kerja di board dengan status yang mencerminkan proses nyata.
  • Batasi pekerjaan yang sedang berjalan (WIP limit) agar tim menyelesaikan sebelum memulai yang baru.
  • Kelola aliran: perhatikan pekerjaan yang macet dan hilangkan penyebabnya.
  • Buat aturan eksplisit, misalnya kapan task boleh masuk Ready atau Done.
  • Perbaiki secara bertahap berdasarkan data dan pengamatan.

Panduan praktisnya ada di Kanban board untuk tim kecil.

Kapan memilih Scrum

Scrum cocok ketika sebagian besar kondisi berikut terpenuhi:

  • Pekerjaan bisa direncanakan per satu atau dua minggu tanpa banyak gangguan.
  • Ada satu orang yang bisa memprioritaskan backlog secara rutin.
  • Stakeholder ingin melihat hasil secara berkala.
  • Tim membangun produk atau fitur baru dengan tujuan yang bisa dirumuskan per sprint.
  • Tim baru belajar agile dan membutuhkan struktur.

Contoh: tim produk yang mengembangkan aplikasi, atau agensi yang mengerjakan fase pengembangan project klien.

Kapan memilih Kanban

Kanban cocok ketika:

  • Pekerjaan datang tidak menentu dan sering mendesak, seperti support, bug produksi, atau permintaan internal.
  • Ukuran pekerjaan sangat bervariasi, dari lima menit sampai beberapa hari.
  • Tim ingin memperbaiki proses yang sudah ada tanpa mengubah peran.
  • Prioritas sering berubah dan menunggu sprint berikutnya terasa terlalu lama.

Contoh: tim customer support, tim operasional, tim konten dengan permintaan harian, atau tim DevOps.

Contoh: satu tim, dua pilihan

Sebuah tim empat orang mengelola aplikasi toko online. Sekitar 60% waktu mereka untuk fitur baru, 40% untuk bug dan permintaan dari tim penjualan.

  • Dengan Scrum: mereka memakai sprint dua minggu dan menyisakan kapasitas sekitar 40% untuk pekerjaan mendadak. Fitur baru direncanakan per sprint. Risikonya, jika pekerjaan mendadak melebihi kapasitas cadangan, Sprint Goal sering gagal.
  • Dengan Kanban: semua pekerjaan masuk ke satu board dengan WIP limit. Bug kritis bisa langsung diambil ketika ada slot kosong. Risikonya, tanpa tujuan per periode, fitur besar bisa terus tertunda oleh pekerjaan kecil.

Tim ini akhirnya memilih Scrum untuk fitur dan aturan Kanban untuk bug: maksimal dua bug In Progress, dan bug kritis boleh masuk sprint kapan saja.

Scrumban: menggabungkan keduanya

Banyak tim memakai kombinasi yang sering disebut Scrumban: ritme perencanaan dan retrospective ala Scrum, ditambah WIP limit dan fokus pada aliran ala Kanban. Contohnya:

  • Planning dan retrospective setiap dua minggu.
  • Board terus berjalan tanpa reset per sprint.
  • WIP limit untuk In Progress dan In Review.
  • Pekerjaan baru diambil dari antrean Ready ketika ada slot kosong.

Scrumban cocok untuk tim yang merasa Scrum terlalu kaku tetapi Kanban murni kurang memberi ritme.

Kesalahan saat memilih

  • Memilih Kanban karena ingin menghindari perencanaan. Kanban tetap membutuhkan prioritas yang jelas dan review rutin.
  • Memilih Scrum tetapi sprint selalu terganggu. Jika lebih dari separuh sprint terganggu pekerjaan mendadak, Kanban atau Scrumban mungkin lebih jujur.
  • Board tanpa WIP limit. Board Kanban tanpa batas pekerjaan hanya daftar task berwarna.
  • Mengganti framework terlalu cepat. Beri waktu minimal empat sprint atau satu bulan sebelum menilai.

Cara memutuskan dalam 10 menit

Jawab tiga pertanyaan berikut bersama tim:

  1. Apakah sebagian besar pekerjaan bisa direncanakan seminggu sebelumnya? Jika ya, condong ke Scrum.
  2. Apakah ada pekerjaan mendadak yang harus dikerjakan dalam hari yang sama? Jika sering, condong ke Kanban.
  3. Apakah stakeholder butuh demo berkala? Jika ya, ritme sprint membantu.

Jika jawabannya campuran, mulai dengan Scrumban dan sesuaikan setelah satu bulan.

Pertanyaan yang sering diajukan

Mana yang lebih mudah untuk pemula, Kanban atau Scrum?

Kanban lebih mudah dimulai karena tidak mengubah peran dan bisa diterapkan di atas proses yang sudah ada. Scrum memberi struktur yang lebih jelas, sehingga sering membantu tim yang belum punya ritme perencanaan sama sekali.

Apakah Kanban dan Scrum bisa memakai board yang sama?

Bisa. Keduanya memakai board dengan status. Bedanya, board Scrum biasanya hanya berisi pekerjaan sprint aktif, sedangkan board Kanban berisi semua pekerjaan yang sedang mengalir.

Apakah Kanban punya daily standup?

Kanban tidak mewajibkan event apa pun, tetapi banyak tim tetap melakukan review board harian singkat. Fokusnya pada aliran pekerjaan: apa yang macet dan apa yang bisa diselesaikan hari ini.

Berapa lama tim perlu mencoba sebelum mengganti framework?

Minimal empat sprint untuk Scrum atau sekitar satu bulan untuk Kanban. Masa awal hampir selalu terasa canggung; yang dinilai adalah apakah prioritas lebih jelas dan masalah terlihat lebih cepat.

Menerapkan Kanban atau Scrum di Moovit

Moovit mendukung keduanya. Untuk Scrum, gunakan Sprints dengan tanggal mulai dan selesai, lalu masukkan task yang mendukung Sprint Goal. Untuk Kanban, gunakan Board dengan status yang disesuaikan melalui Settings. WIP limit adalah kesepakatan tim yang dijaga bersama saat melihat board. Reports membantu memantau flow time dan pekerjaan yang lama tertahan.

Pelajari lebih lanjut di panduan metode agile, atau buat akun Moovit dan coba framework pilihan tim Anda.