Batas WIP: Cara Menetapkannya dalam Kanban (Dengan Contoh)

Batas work in progress (WIP) adalah salah satu cara tercepat untuk meningkatkan kecepatan pekerjaan mengalir melalui sebuah tim. Tetapkan sebuah angka di atas setiap kolom pada papan Kanban Anda, dan aturannya sederhana: tidak ada yang memulai pekerjaan baru jika kolom tersebut sudah mencapai batasnya.

Fakta Kunci

• Tim yang menegakkan batas WIP melaporkan cycle time 2 kali lebih cepat dibandingkan tim tanpa batasan, menurut survei praktisi Kanban University (2023).
• Context switching menghabiskan rata-rata 23 menit bagi pekerja untuk sepenuhnya fokus kembali setelah sebuah gangguan, yang bertambah parah ketika beberapa tugas berjalan bersamaan (University of California, Irvine, 2023).
• Rata-rata tim software mengerjakan 3 hingga 5 tugas aktif per orang dalam satu waktu, namun throughput puncak biasanya dicapai dengan 1 hingga 2 tugas per orang (State of Agile Report, edisi ke-17, 2024).

Apa Itu Batas WIP?

Batas WIP (batas work in progress) adalah batasan eksplisit atas berapa banyak item yang bisa ada dalam satu tahap workflow tertentu pada saat yang sama. Dalam sistem Kanban, setiap kolom papan mewakili satu tahap, dan batas WIP berada di atas kolom tersebut sebagai sebuah angka. Ketika sebuah kolom mencapai batasnya, tidak ada yang menarik pekerjaan baru ke dalamnya sampai sesuatu bergerak maju.

Konsep ini berasal langsung dari lean manufacturing, di mana Toyota menggunakan sistem yang disebut "kartu kanban" untuk mengendalikan alur produksi di lantai pabrik. Idenya adalah bahwa overproduksi merupakan pemborosan, dan prinsip yang sama berlaku untuk pekerjaan berbasis pengetahuan: semakin banyak hal yang Anda mulai tanpa menyelesaikannya, semakin lambat segalanya berjalan.

Batas WIP tidak memberi tahu Anda apa yang harus dikerjakan selanjutnya. Batas ini memberi tahu Anda kapan harus berhenti memulai hal-hal baru dan mulai menyelesaikan yang sudah ada.

Mengapa Membatasi Work in Progress?

Argumen untuk batas WIP bertumpu pada sebuah rumus yang disebut Hukum Little, yang menyatakan:

Cycle Time = WIP / Throughput

Dalam bahasa sederhana: jika tim Anda memiliki 20 item yang sedang dikerjakan dan menyelesaikan 5 per minggu, rata-rata cycle time adalah 4 minggu. Potong WIP menjadi 10 item dan cycle time turun menjadi 2 minggu, tanpa tim harus bekerja lebih keras.

Perhitungannya terdengar hampir terlalu rapi, tetapi mekanisme yang mendasarinya nyata. Berikut yang terjadi tanpa batasan:

Context switching membunuh fokus. Setiap kali seseorang mengambil tugas baru sebelum menyelesaikan tugas lama, mereka membayar biaya peralihan mental. Biaya itu tidak sepele. Riset dari UC Irvine menempatkannya lebih dari 20 menit hilangnya fokus per gangguan. Kalikan itu dengan 3-5 tugas bersamaan per orang dan Anda telah diam-diam menghabiskan sebagian besar hari kerja hanya untuk overhead transisi.

Antrean panjang menyembunyikan masalah. Ketika pekerjaan menumpuk di satu kolom, hal itu menjadi tidak terlihat. Tidak ada yang menyadari bahwa sebuah tugas review sudah tak tersentuh selama tiga hari, karena papan sudah begitu penuh sehingga keterlambatan itu tidak menonjol. Batas WIP mengungkap bottleneck ini secara langsung. Jika kolom "In Review" mencapai batasnya, tim harus membicarakan mengapa item-item tidak bergerak.

Metrik flow mencerminkan ini secara langsung. Jika Anda menggunakan diagram flow kumulatif, pita yang lebar di tahap tengah adalah tanda visual dari WIP yang tinggi. Pita yang sempit dan paralel berarti WIP terkendali dan pekerjaan mengalir dengan baik. Velocity dalam agile juga cenderung membaik begitu batas WIP menstabilkan seberapa banyak yang dikomitmenkan tim per siklus.

Cara Menetapkan Batas WIP

Tidak ada rumus universal yang cocok untuk setiap tim. Namun langkah-langkah berikut memberi Anda titik awal yang bisa disesuaikan seiring waktu.

Langkah 1: Hitung kapasitas tim Anda

Mulailah dengan jumlah orang yang bekerja di setiap tahap. Kolom pengembangan dengan 4 developer bisa menangani lebih banyak item bersamaan dibandingkan kolom review yang hanya diisi 1 atau 2 orang.

Aturan awal yang umum: 2 item per orang per kolom. Jadi kolom pengembangan dengan 4 orang mulai dengan batas WIP sebesar 8.

Langkah 2: Lihat WIP aktual Anda saat ini

Sebelum menetapkan batasan apa pun, hitung berapa banyak item yang sebenarnya ada di setiap kolom hari ini. Ini adalah baseline Anda. Jika kolom "In Progress" sudah memiliki 14 item untuk tim beranggotakan 3 orang, Anda punya gambaran yang jelas mengapa pekerjaan butuh waktu lama untuk selesai.

Langkah 3: Tetapkan batas sedikit di bawah rata-rata Anda saat ini

Jika rata-rata WIP per kolom Anda adalah 10, mulailah batas Anda di 7 atau 8, bukan 3. Batas yang terlalu ketat menyebabkan lebih banyak gangguan daripada yang bisa diselesaikannya, terutama di awal. Anda ingin tim merasakan batasannya dan merespons, bukan merasa lumpuh.

Langkah 4: Tegakkan batas sebagai pemicu percakapan, bukan blokir keras

Ketika sebuah kolom mencapai batasnya, tugas tim adalah bergotong royong (swarm) pada pekerjaan yang terhambat dan menuntaskannya sebelum menarik hal baru. Di sinilah batas WIP mengubah perilaku tim. "Bisakah kita bantu meloloskan item ini melalui review?" menjadi kebiasaan harian, bukan renungan belakangan.

Langkah 5: Tinjau dan sesuaikan setiap dua minggu

Setelah dua sprint atau dua minggu, lihat burndown chart dan data cycle time Anda. Jika item mengalir lebih cepat, perketat batasnya. Jika tim merasa terus-menerus terhambat, longgarkan sedikit. Batas WIP adalah kenop yang bisa diputar, bukan aturan yang terukir di batu.

Batas WIP per Kolom Papan

Berikut tabel referensi untuk tim software tipikal yang menggunakan papan Kanban empat kolom. Ini adalah titik awal, bukan resep baku.

Untuk tim beranggotakan 4 developer, konfigurasi awal yang masuk akal adalah: To Do (tanpa batas), In Progress (6), In Review (3), Done (tanpa batas). Itu menjaga kolom pengembangan agar tidak menjadi bottleneck dan memaksa review tetap ramping.

Jika tim Anda menggunakan Scrum dengan sprint dua mingguan, Anda bisa menerapkan batas WIP pada papan sprint dengan cara yang sama. Logikanya identik, meski kerangkanya berbeda. Perbedaan Scrum vs Kanban tidak mengubah matematika dasar Hukum Little.

Kesalahan Umum Saat Menetapkan Batas WIP

Menetapkan batasan lalu mengabaikannya. Batas WIP yang bisa dilewati orang tidak benar-benar ada. Jika tim rutin membuat "pengecualian" untuk melewati batasnya, berarti batasan itu tidak ditegakkan. Bangun kebiasaannya sebelum Anda membangun prosesnya.

Menerapkan satu angka untuk semua kolom. Kolom review dengan 2 reviewer dan kolom pengembangan dengan 5 developer memiliki throughput yang sama sekali berbeda. Satu ukuran tidak cocok untuk siapa pun di sini.

Membuat batas terlalu rendah terlalu cepat. Jika Anda menurunkan dari 15 item per kolom menjadi 3 dalam semalam, Anda akan menciptakan kepanikan dan resistensi. Pengetatan bertahap memberi tim waktu untuk menyesuaikan workflow dan memunculkan masalah yang selama ini disembunyikan oleh WIP yang tinggi.

Melupakan item yang terhambat (blocker). Batas WIP juga menghitung item yang terhambat. Jika 3 dari 6 tugas "In Progress" Anda terhambat oleh ketergantungan eksternal, Anda sebenarnya hanya punya 3 slot kapasitas nyata. Melacak blocker secara terpisah membantu menjaga gambaran tetap akurat.

Tidak menyesuaikan untuk story point. Sebagian tim menetapkan batas berdasarkan jumlah item, yang lain berdasarkan story point. Jika tugas Anda sangat bervariasi ukurannya (tugas 1 poin berdampingan dengan epic 13 poin), hitung berdasarkan poin untuk mendapatkan gambaran beban yang lebih jujur.

Manfaat Batas WIP

Ketika tim benar-benar menegakkan batasannya, beberapa hal secara konsisten terjadi:

Pekerjaan selesai lebih cepat. Cycle time turun karena item tidak menunggu lama. Ketika tim hanya boleh memiliki 5 hal yang sedang dikerjakan, setiap satu dari 5 item itu mendapat perhatian harian.

Bottleneck langsung terlihat. Sebuah kolom yang selalu berada di batasnya sedang memberi tahu Anda sesuatu. Tim tidak bisa mengabaikannya karena itu menghambat semua yang lain.

Percakapan tim membaik. Batas WIP menciptakan momen alami untuk bertanya "kenapa ini macet?" alih-alih membiarkan keterlambatan menjadi tak terlihat. Standup harian menjadi lebih fokus pada pertanyaan yang sama: apa yang menghambat progres saat ini?

Perencanaan menjadi lebih jujur. Ketika tim melihat sebuah kolom penuh, mereka berhenti berkomitmen pada pekerjaan baru yang tidak bisa mereka tangani. Overcommitment berkurang, dan perkiraan membaik. Ini terhubung langsung dengan bagaimana velocity dalam agile menjadi stabil begitu WIP terkendali.

Stres berkurang. Secara berlawanan dengan intuisi, diberi tahu "Anda hanya boleh mengerjakan 5 hal" lebih tidak membuat stres dibandingkan diberi tahu "selesaikan semua 15 ini." Orang-orang tahu apa yang harus difokuskan.

Pertanyaan yang Sering Diajukan

Apa itu batas WIP dalam Kanban? Batas WIP adalah angka yang ditempatkan di atas kolom Kanban yang membatasi berapa banyak item pekerjaan yang bisa ada dalam tahap tersebut sekaligus. Ketika sebuah kolom mencapai batasnya, anggota tim harus membantu menuntaskan pekerjaan yang ada sebelum menarik hal baru.

Bagaimana cara menghitung batas WIP yang tepat? Mulailah dengan 2 item per orang di setiap kolom, lalu amati selama dua minggu. Jika pekerjaan mengalir dan cycle time membaik, perketat batasnya. Jika tim merasa terus-menerus terhambat, longgarkan. Tidak ada satu angka yang benar-benar tepat. Tujuannya adalah menemukan batasan yang memunculkan bottleneck tanpa melumpuhkan throughput.

Bisakah batas WIP diterapkan di luar Kanban? Bisa. Tim Scrum menerapkan batas WIP pada papan sprint. Bahkan tim yang menggunakan metode hibrida atau daftar tugas sederhana pun bisa mendapat manfaat dari batasan informal atas berapa banyak hal yang ditangani setiap orang sekaligus. Logika yang mendasarinya, Hukum Little, berlaku untuk sistem antrean apa pun.

Apa yang terjadi ketika batas WIP tercapai? Tim berhenti menarik pekerjaan baru ke dalam kolom tersebut dan fokus menuntaskan item yang ada. Dalam praktiknya, ini sering berarti bergotong royong pada tugas yang terhambat atau melakukan review dadakan untuk membebaskan seseorang di tahap berikutnya. Batas ini menciptakan urgensi tanpa perlu campur tangan manajer.

Haruskah kolom "To Do" memiliki batas WIP? Biasanya tidak, atau setidaknya bukan yang ketat. To Do berfungsi sebagai backlog. Batasan longgar (seperti 2x kapasitas sprint) bisa mencegah kolom itu menjadi tempat pembuangan, tetapi batasan keras cenderung menciptakan urgensi buatan pada item yang belum siap dikerjakan.

---

Batas WIP adalah perubahan kecil dengan efek besar terhadap flow tim. Begitu Anda melihat sebuah bottleneck muncul untuk pertama kalinya karena sebuah kolom mencapai batasnya, mekanismenya langsung terasa. Dari sana, tinggal soal menyesuaikan angkanya. Lacak cycle time Anda dengan diagram flow kumulatif dan amati apa yang terjadi pada pita-pitanya ketika WIP turun.