Kenapa Velocity Menipu — dan Metrik Apa yang Lebih Jujur
Velocity itu bukan ukuran kecepatan. Dia ukuran volume tebakan.
Isi
Velocity = jumlah story point yang "selesai" dalam satu sprint. Masalahnya: story point bukan satuan fisik. Dia estimasi relatif hasil musyawarah tim. Tidak ada standar industri. 5 poin di tim A bisa jadi 2 poin di tim B, dan 13 poin di sprint ini bisa jadi 8 poin bulan depan untuk kerjaan yang sama persis.
Artinya velocity cuma valid untuk satu tim, dibandingkan dengan dirinya sendiri, dalam kondisi stabil. Begitu dipakai untuk hal lain, dia jadi angka fiksi yang kelihatan ilmiah.
Empat cara velocity menipu
1. Estimasi jadi target, bukan prediksi. Tim tahu velocity dipajang di dashboard. Estimasi naik pelan-pelan. Bukan karena kerjaan lebih berat — karena insentifnya begitu. Ini Goodhart's Law klasik: begitu sebuah ukuran jadi target, dia berhenti jadi ukuran yang baik.
2. Inflasi poin lewat pemecahan tiket. Satu fitur dipecah jadi 6 tiket kecil, masing-masing 2 poin = 12 poin. Dikerjakan utuh sebagai 1 tiket = 8 poin. Kerjaan sama, angka beda 50%. Tim yang belajar "cara main" akan menang angka, bukan menang hasil.
3. Poin tidak menangkap kerja yang tidak terlihat. Code review, bugfix production, meeting, bantu tim lain, dokumentasi, on-call — sering nol poin. Tim yang velocity-nya turun bisa jadi justru sedang menjaga sistem tetap hidup. Velocity tidak tahu itu.
4. Comparasi antar tim = omong kosong. Sering muncul di meeting lintas divisi: "Tim A velocity-nya 60, tim B cuma 30, berarti B lambat." Tidak. B mungkin pakai skala 1-3, A pakai 1-21. Atau B kerja di legacy code dengan test suite 4 jam. Angka itu tidak sebanding.
Anti-pattern lapangan yang paling sering
- Velocity sebagai KPI individu. Langsung rusak. Orang akan ambil tiket gampang, hindari kerja keras.
- "Kenapa velocity sprint ini turun?" sebagai pertanyaan retoris di retro. Ini bukan pertanyaan, ini tuduhan. Hasilnya tim belajar defensif, bukan belajar memperbaiki.
- Sprint commitment dihitung dari rata-rata velocity. Rata-rata historis bukan janji. Kalau sprint ini ada libur, cuti, atau dependensi eksternal, angka rata-rata bohong.
- Burn-down chart yang dirapikan. Kalau garisnya kelihatan bagus terus tapi scope berubah diam-diam, grafiknya cuma dekorasi.
Yang lebih jujur
Kalau butuh prediksi kapasitas → pakai throughput, bukan poin. Hitung jumlah item yang selesai per minggu (tanpa poin sama sekali). Item yang sudah dipecah cukup kecil (≤2 hari) jadi hitungannya stabil. Setelah 6-8 minggu, kamu punya distribusi, bukan satu angka. Lalu ramal dengan rentang: "biasanya 7-11 item per minggu" — bukan "velocity kita 34".
Kalau butuh tahu sistem sehat atau tidak → pakai empat metrik DORA. Dari riset DORA (Google Cloud, laporan tahunan Accelerate State of DevOps):
| Metrik | Arti | Arah bagus |
|---|---|---|
| Deployment frequency | seberapa sering rilis ke production | naik |
| Lead time for changes | commit → production | turun |
| Change failure rate | % deploy yang butuh perbaikan/rollback | turun |
| Time to restore | lama pulih setelah insiden | turun |
Keempatnya berpasangan: frequency tanpa stability = kacau; stability tanpa frequency = lambat. Ini mengukur aliran dan risiko, bukan tebakan volume.
Kalau butuh tahu kerja tersendat di mana → pakai Little's Law.
Waktu tunggu = Jumlah kerja dalam proses ÷ Throughput
Contoh konkret: 24 tiket sedang in-progress, throughput 6 tiket/minggu → rata-rata tiket nunggu 4 minggu. Solusinya bukan "kerja lebih cepat", tapi kurangi WIP. Batasi kolom "In Progress" maksimal 3 per orang. Ini satu perubahan papan Kanban yang efeknya biasanya lebih besar daripada menambah orang.
Kalau butuh sinyal kualitas → hitung escaped defects. Bug yang lolos ke production per bulan, dibagi jumlah rilis. Sederhana, sulit dimanipulasi, dan langsung terasa oleh user.
Satu hal yang bisa langsung dipakai
Buka papan sprint kamu sekarang. Cek kolom "In Progress".
Kalau isinya lebih dari jumlah orang di tim, kamu punya masalah WIP, bukan masalah kecepatan.
Pasang batas WIP eksplisit di papan (fisik atau di Jira/Linear): maksimal 1-2 item aktif per orang. Aturan tambahan: tidak boleh tarik tiket baru sebelum yang lama pindah kolom. Jalankan 2 sprint, lalu bandingkan lead time — bukan velocity.
Kalau velocity kamu masih dipajang di dashboard manajemen, ganti labelnya jadi "estimasi internal tim" dan tambahkan rentang, bukan angka tunggal.
Takeaway
Velocity mengukur seberapa besar tebakan tim, bukan seberapa cepat kerja selesai. Ukur aliran (lead time, throughput) dan hasil (deploy frequency, change failure rate) — bukan volume poin.
Catatan: angka-angka DORA di atas adalah nama metrik dari riset DORA/Google Cloud, bukan angka benchmark spesifik. Untuk benchmark terbaru per tahun, cek laporan resmi DORA di dora.dev — angkanya berubah tiap tahun dan berbeda per industri.