Velocity dalam Agile: Cara Mengukur Throughput Tim

Velocity agile adalah salah satu angka paling praktis yang bisa dilacak oleh tim Scrum. Angka ini memberi tahu Anda, rata-rata, seberapa banyak pekerjaan yang benar-benar diselesaikan tim Anda dalam satu sprint, yang menjadi fondasi bagi perkiraan rilis atau rencana kapasitas yang jujur.

Sebagian besar tim mendengar tentang velocity di awal perjalanan agile mereka, salah menggunakannya sebagai skor kinerja, lalu bertanya-tanya mengapa itu menciptakan tekanan alih-alih kejelasan. Panduan ini menjelaskan apa itu velocity, cara menghitungnya dengan benar, dan cara menggunakannya sebagai alat perkiraan tanpa memanipulasi angkanya.

Apa Itu Velocity dalam Agile?

Velocity agile adalah rata-rata jumlah story point yang diselesaikan tim dalam satu sprint. Velocity dihitung dengan membagi total poin yang diselesaikan di beberapa sprint terakhir dengan jumlah sprint tersebut.

Itulah keseluruhan definisinya. Velocity tidak mengukur kualitas, kecepatan, efisiensi, atau upaya. Velocity hanya mengukur throughput yang selesai dalam rentang waktu tetap, tidak lebih dari itu.

Kata kuncinya adalah "selesai". Story point yang sudah dimulai tetapi belum tuntas sebelum sprint berakhir tidak dihitung ke dalam velocity. Nilai parsial tidak berlaku di sini. Ketegasan inilah yang membuat velocity menjadi input perkiraan yang andal: jika sebuah tim memiliki rata-rata velocity 42 poin, Anda bisa memproyeksikan sprint mendatang dengan cukup percaya diri karena angka tersebut mencerminkan apa yang benar-benar dikirim, bukan apa yang dicoba.

Fakta Kunci

• Tim yang melacak velocity setidaknya selama 6 sprint menghasilkan estimasi tanggal rilis yang 40% lebih akurat dibandingkan tim yang mengestimasi hanya berdasarkan firasat (Scrum Alliance State of Scrum, 2023).
• Rata-rata velocity tim Scrum berkisar antara 20 hingga 60 story point per sprint, meskipun angka itu sendiri kurang penting dibandingkan stabilitasnya dari waktu ke waktu (VersionOne State of Agile, 2023).
• Sekitar 60% tim agile melaporkan menggunakan velocity sebagai metrik utama perencanaan kapasitas mereka, menjadikannya ukuran throughput yang paling banyak diadopsi dalam Scrum (Digital.ai State of Agile Report, 2023).

Cara Menghitung Velocity

Rumusnya sederhana.

Velocity = Total story point yang diselesaikan / Jumlah sprint yang diukur

Gunakan 3 hingga 5 sprint terakhir untuk rata-rata bergulir. Kurang dari 3 sprint memberikan gambaran yang berisik (noisy); lebih dari 7 mulai mencampurkan data dari periode ketika tim memiliki komposisi atau kebiasaan estimasi yang berbeda.

Berikut contoh perhitungan untuk tim yang menjalankan sprint 2 minggu:

Rata-rata velocity bergulir (4 sprint): (42 + 44 + 39 + 45) / 4 = 42,5 poin

Velocity kerja tim tersebut kira-kira 42 poin per sprint. Perhatikan bahwa angka yang dikomitmenkan tidak berpengaruh pada perhitungan ini. Yang penting adalah apa yang melewati garis "selesai" sebelum sprint berakhir. Jika Sprint 3 terlihat rendah, selidiki penyebabnya (perubahan ruang lingkup? hambatan di tengah sprint? hari libur?) alih-alih mengabaikannya atau menggelembungkannya.

Cara Menggunakan Velocity untuk Perkiraan

Setelah Anda memiliki velocity yang stabil, Anda bisa menjawab pertanyaan yang akhirnya ditanyakan setiap stakeholder: "Kapan ini akan selesai?"

Pendekatannya sederhana. Jumlahkan story point pada sisa backlog Anda (atau irisan backlog untuk rilis tertentu), lalu bagi dengan rata-rata velocity Anda.

Sprint hingga selesai = Poin backlog yang tersisa / Rata-rata velocity

Misalkan tim Anda memiliki 210 poin tersisa dalam backlog rilis dan velocity 42. Itu berarti 5 sprint, atau 10 minggu dengan siklus 2 mingguan. Itulah perkiraan Anda.

Beberapa praktik membuat ini lebih berguna dalam praktik:

• Gunakan rentang, bukan estimasi satu titik. Masukkan hasil sprint terakhir Anda yang paling rendah dan yang paling tinggi untuk mendapatkan pita kepercayaan. "Antara 4,5 dan 6 sprint" lebih jujur daripada "tepat 5."
• Perkirakan ulang setiap sprint. Seiring tim menyelesaikan pekerjaan, menambahkan item baru, atau menghapus ruang lingkup, proyeksinya bergeser. Perlakukan sebagai angka yang hidup, bukan kontrak.
• Hubungkan velocity dengan kebiasaan penyempurnaan backlog Anda. Perkiraan velocity hanya sebaik sprint planning yang menjaga backlog tetap terukur dan terurut. Jika estimasi melenceng atau backlog menjadi basi, velocity kehilangan daya perkiraannya.
• Kaitkan dengan milestone roadmap. Jika roadmap Anda menyatakan sebuah fitur akan rilis di Q3, hitung mundur dari tenggat tersebut untuk melihat berapa banyak sprint yang Anda miliki, kalikan dengan velocity, dan periksa apakah sisa ruang lingkupnya sesuai. Jika tidak, Anda perlu membicarakan ruang lingkup atau linimasa lebih awal, bukan saat tenggat tiba.

Metode perkiraan ini juga cocok dipadukan dengan planning poker, yang membantu menjaga estimasi story point tetap terkalibrasi di seluruh tim sehingga velocity tetap bermakna dari waktu ke waktu.

Apa yang BUKAN Velocity

Di sinilah sebagian besar tim melakukan kesalahan.

Velocity bukan metrik produktivitas. Tim dengan velocity 60 tidak "lebih baik" daripada tim dengan velocity 30. Story point bersifat relatif terhadap skala masing-masing tim. Satu tim mungkin mengukur sebuah fitur sebesar 8 poin; tim lain mungkin mengukur fitur yang sama sebesar 3 poin. Tidak ada satuan bersama. Membandingkan velocity antar tim tidak ada artinya.

Velocity bukan target untuk ditingkatkan. Ketika manajer menetapkan "tingkatkan velocity sebesar 20%" sebagai tujuan, tim melakukan satu hal yang bisa diprediksi: mereka menggelembungkan estimasi story point mereka. Angkanya naik, tapi output sebenarnya tidak berubah. Anda baru saja merusak kalibrasi sistem estimasi Anda.

Velocity bukan ukuran kinerja individu. Velocity adalah milik tim, bukan milik satu orang. Menggunakannya untuk mengevaluasi individu menciptakan insentif yang salah dan merusak estimasi kolaboratif yang membuat metrik ini akurat.

Velocity bukan komitmen. Stakeholder terkadang memperlakukan velocity sebagai batas bawah: "Anda mencapai 44 poin sprint lalu, jadi Anda berkomitmen setidaknya 44 poin sprint ini." Bukan begitu cara kerjanya. Velocity adalah rata-rata historis yang digunakan untuk perencanaan, bukan kewajiban throughput minimum.

Faktor yang Memengaruhi Velocity

Velocity berubah seiring waktu, dan sebagian besar perubahan itu memiliki penyebab yang jelas. Mengetahui apa yang mendorong variasi ini membantu Anda menafsirkan angkanya alih-alih bereaksi terhadapnya.

Perubahan komposisi tim. Ketika anggota baru bergabung, velocity biasanya turun selama 2 hingga 3 sprint sementara mereka beradaptasi. Ketika seseorang keluar, efeknya langsung terasa. Tidak ada perubahan yang berarti tim gagal.

Hari libur dan cuti. Sprint yang bersinggungan dengan hari libur nasional atau memiliki banyak orang yang cuti akan menghasilkan velocity yang lebih rendah. Beberapa tim menyesuaikan kapasitas sprint mereka sesuai kondisi tersebut; yang lain hanya mencatatnya saat meninjau rata-rata.

Perubahan ruang lingkup di tengah sprint. Menarik pekerjaan yang tidak direncanakan atau menukar story di tengah sprint merusak hubungan antara apa yang direncanakan dan apa yang diselesaikan. Ini salah satu alasan mengapa batas WIP itu penting: membatasi pekerjaan yang sedang berjalan melindungi sprint dari gangguan di tengah jalan.

Pergeseran estimasi. Selama berbulan-bulan, tim terkadang secara tidak sadar mengubah cara mereka mengukur pekerjaan. "Story 5 poin" di bulan pertama mungkin terasa seperti "story 3 poin" pada bulan keenam seiring tim semakin cepat dalam pekerjaan serupa. Jika velocity terus naik secara stabil tanpa perubahan pada ukuran tim atau perkakas, periksa apakah estimasinya bergeser alih-alih mengasumsikan tim benar-benar lebih cepat.

Utang teknis dan gesekan lingkungan. Pipeline CI yang lambat, insiden produksi yang sering, dan masalah kualitas kode menghabiskan kapasitas sprint tanpa terlihat dalam backlog. Tim yang membawa utang teknis signifikan sering memiliki velocity yang lebih rendah dan lebih fluktuatif dibandingkan kapasitas yang seharusnya mereka miliki.

Velocity vs Metrik Flow Lainnya

Velocity adalah metrik tingkat sprint. Metrik ini memberi tahu Anda tentang throughput di seluruh kotak waktu tetap. Tetapi metrik ini tidak memberi tahu Anda segalanya tentang bagaimana pekerjaan mengalir melalui sistem Anda.

Velocity dan diagram flow kumulatif saling melengkapi. Velocity memberi Anda angka perkiraan tingkat sprint; CFD menunjukkan apakah workflow Anda cukup sehat untuk mempertahankannya. Tim dengan velocity baik tetapi CFD yang tidak stabil (pita WIP yang membesar, persilangan pita yang sering terjadi) sedang menuju penurunan velocity.

Cara Meningkatkan (Menstabilkan) Velocity

Tujuannya bukan memaksimalkan velocity. Tujuannya adalah membuat velocity dapat diprediksi, sehingga perkiraan Anda bisa dipercaya. Berikut cara mencapainya.

1. Jalankan sprint yang konsisten. Panjang sprint yang bervariasi (bergonta-ganti antara 1 minggu dan 2 minggu) membuat data velocity tidak bisa dibandingkan. Pilih satu siklus dan pertahankan setidaknya selama 6 sprint sebelum menarik kesimpulan.

2. Selesaikan definition of done sebelum menutup story. Jika definition of done tim Anda tidak jelas, story melewati garis selesai pada tingkat kualitas yang berbeda-beda, membuat poin tidak bisa dibandingkan. Pertajam definisinya dan tegakkan.

3. Lindungi sprint dari pekerjaan yang tidak direncanakan. Setiap "kebakaran" di tengah sprint yang menarik seorang developer keluar adalah pukulan langsung terhadap velocity. Bangun proses triase yang ringan (filter product owner, aturan "break glass") yang mengarahkan item mendesak tanpa merusak komitmen sprint.

4. Jaga estimasi tetap terkalibrasi. Jalankan latihan kalibrasi ulang singkat setiap kuartal. Ambil 5 hingga 10 story yang sudah selesai dan estimasi ulang dengan tim saat ini. Jika estimasi baru berbeda signifikan dari yang asli, data velocity Anda dari sebelum pergeseran itu perlu penyesuaian mental.

5. Lacak penyebab sprint yang menyimpang (outlier). Ketika velocity melonjak atau turun lebih dari 20% dari rata-rata bergulir, catat penyebabnya dalam retrospektif sprint Anda. Pola akan terlihat: jika sprint yang mengandung hari libur konsisten turun 25%, Anda bisa memperhitungkannya dalam perencanaan kapasitas.

6. Gunakan penyempurnaan backlog secara konsisten. Item backlog yang belum disempurnakan menghasilkan estimasi yang tidak dapat diandalkan, yang menghasilkan velocity yang berisik. Tim yang melakukan penyempurnaan secara rutin mempertahankan velocity yang lebih stabil karena mereka bekerja dari story yang sudah dipahami dengan baik dan berukuran tepat.

7. Kurangi perubahan ruang lingkup. Perubahan ruang lingkup yang sering di tengah sprint adalah pendorong terbesar tunggal ketidakstabilan velocity bagi sebagian besar tim. Sprint yang stabil dengan perubahan ruang lingkup minimal menghasilkan velocity yang stabil.

Pertanyaan yang Sering Diajukan

Berapa banyak data sprint yang saya butuhkan sebelum velocity bisa diandalkan? Sebagian besar praktisi merekomendasikan setidaknya 5 hingga 6 sprint yang sudah selesai sebelum memperlakukan velocity sebagai input perkiraan. Sebelum itu, Anda melihat sampel yang terlalu kecil untuk menyaring noise. Selama beberapa sprint pertama, perlakukan velocity sebagai arah, bukan prediksi.

Bagaimana jika velocity kami berubah drastis dari sprint ke sprint? Varians yang tinggi biasanya menandakan salah satu dari beberapa hal: panjang sprint yang tidak konsisten, perubahan ruang lingkup yang sering di tengah sprint, tim yang baru saja berubah, atau pergeseran estimasi. Mulailah dengan mencatat penyebab setiap sprint outlier dalam retrospektif Anda. Setelah Anda bisa menjelaskan variasinya, Anda bisa mengatasi akar penyebabnya alih-alih hanya merata-ratakan di sekitar noise-nya.

Haruskah kami membagikan velocity kepada stakeholder? Bagikan perkiraan rilisnya, bukan angka mentahnya. Stakeholder yang melihat angka velocity secara terpisah sering memperlakukannya sebagai target atau tolok ukur dibandingkan tim lain. Perkiraan ("rilis ini sesuai jalur untuk Q3 berdasarkan kecepatan saat ini") memberi mereka apa yang mereka butuhkan tanpa menciptakan tekanan yang salah.

Bisakah kami menggunakan velocity tanpa story point? Bisa. Beberapa tim melacak velocity dalam jumlah story, bukan poin, yang berfungsi jika story mereka secara konsisten memiliki ukuran yang serupa. Yang lain menggunakan T-shirt size yang dikonversi ke skala numerik. Kuncinya adalah satuan apa pun yang Anda gunakan tetap konsisten cukup lama untuk membangun rata-rata yang bermakna.

Bagaimana velocity berbeda dari kapasitas? Kapasitas adalah ketersediaan yang direncanakan (total jam tim dalam satu sprint). Velocity adalah throughput aktual (poin yang diselesaikan). Kapasitas adalah input; velocity adalah output. Tim terkadang menggunakan kapasitas untuk menetapkan tujuan sprint, tetapi mereka menggunakan velocity untuk memperkirakan rilis mendatang. Mencampuradukkan keduanya menyebabkan overcommitment: sprint pada kapasitas 100% tidak menjamin 100% dari poin yang direncanakan akan selesai.

---

Velocity adalah angka yang sederhana, tetapi tim mendapatkan manfaat terbesar darinya ketika mereka berhenti mengejarnya dan mulai membacanya. Velocity yang stabil berarti kebiasaan estimasi dan pengiriman Anda cukup konsisten untuk dijadikan dasar perencanaan. Ketika velocity bergeser, itu adalah informasi: ada sesuatu di lingkungan atau proses tim yang berubah, dan itu layak untuk dipahami.

Padukan dengan disiplin sprint planning, estimasi story point yang bersih, dan visibilitas flow dari diagram flow kumulatif Anda, dan Anda memiliki sistem perkiraan yang benar-benar bisa dipercaya oleh stakeholder.