Panduan Scrum | 34. Kecepatan dalam Scrum – Kecepatan Tim Pengembang

Diterbitkan: 2022-07-06

Velocity di Scrum membantu Anda untuk menentukan tingkat di mana Tim Scrum menyelesaikan tugas. Kita dapat mendefinisikannya sebagai jumlah rata-rata Poin Cerita yang diselesaikan dalam satu Sprint. Velocity juga dapat memperkirakan durasi suatu proyek berdasarkan kemajuan pekerjaan yang telah diselesaikan. Namun, ini hanya masuk akal untuk tim yang matang yang bekerja dengan kecepatan yang seimbang dan stabil. Lihatlah apa itu Velocity dan bagaimana membuatnya bekerja paling baik untuk Anda!

Kecepatan dalam Scrum – daftar isi:

  1. Kecepatan dalam Scrum – Pendahuluan
  2. Kecepatan aktual dan yang direncanakan
  3. Kesulitan dan risiko yang terkait dengan Velocity di Scrum
  4. Ringkasan

Kecepatan dalam Scrum – Pendahuluan

Velocity adalah metode opsional tetapi populer untuk mengukur kecepatan Tim Scrum. Ini karena perkiraan Kecepatan yang akurat memungkinkan memprediksi, sampai batas yang wajar, waktu yang dibutuhkan untuk menyelesaikan sebuah proyek. Namun, ini adalah ukuran yang hanya dapat diterapkan pada Tim Pengembang tertentu, yang akan melakukan tugas yang telah "dinilai" dengan sendirinya menggunakan unit yang sudah dikenal, seperti Poin Cerita, misalnya.

Kecepatan Tim Pengembang paling sering disajikan dalam bentuk Bagan Kecepatan. Pada sumbu X ditandai Sprint berturut-turut. Di sumbu Y, di sisi lain, kita akan menemukan jumlah Poin Cerita atau unit terkait lainnya yang diselesaikan dalam Sprint yang diberikan. Dengan Bagan Kecepatan, Tim Scrum memperoleh pandangan yang jelas tentang perubahan dalam kecepatan kerjanya. Jika garis yang ditandai pada grafik naik, itu berarti Tim sedang mengoptimalkan efisiensinya atau mengurangi nilai Poin Cerita. Oleh karena itu, baik Scrum Master maupun Pemilik Produk harus dengan hati-hati mengikuti garis yang menunjukkan Kecepatan Tim.

velocity in scrum - speed of the development team

Kecepatan aktual dan yang direncanakan

Kecepatan aktual dari Tim Pengembang menggambarkan kecepatan kerja dalam Sprint yang telah diselesaikan dan dihitung pada akhir setiap Sprint. Dibutuhkan nilai jumlah Poin Cerita untuk semua Cerita Pengguna yang diselesaikan. Kecepatan aktual dari Tim Pengembang memungkinkan Anda untuk merencanakan dan memperkirakan dengan beberapa kemungkinan kecepatan tugas di masa depan.

Kecepatan yang direncanakan, di sisi lain, diperkirakan berdasarkan nilai rata-rata dari Kecepatan sebenarnya. Hal ini membutuhkan asumsi tidak ada perubahan dalam Tim Pengembang. Ini adalah alat internal yang penting bagi Tim Pengembang, yang berdasarkan itu dapat menilai apakah kerja sama dalam Tim berjalan dengan baik dan apakah kecepatan kerja dipertahankan.

Planned Velocity juga memungkinkan Pemilik Produk untuk memperkirakan waktu eksekusi dari User Stories yang terdefinisi dengan baik yang dijadwalkan untuk dieksekusi di Sprint berikutnya. Ini memungkinkan pemeliharaan Product Backlog yang lebih efisien, yang kami tulis di artikel ini. Namun, praktik penerapan Velocity yang direncanakan untuk memperkirakan durasi proyek tidak sesederhana itu.

Kesulitan dan risiko yang terkait dengan Velocity di Scrum

Kecepatan dalam Scrum sering dianggap terlalu penting tanpa mempertimbangkan faktor-faktor berikut:

  • memperkirakan keseluruhan yang lebih besar atau keseluruhan proyek – sementara Tim Pengembang dapat secara akurat memperkirakan jumlah Poin Cerita yang akan ditugaskan ke tugas tertentu, sangat sulit atau tidak mungkin untuk menggambarkan keseluruhan yang lebih besar untuk implementasi di masa mendatang di unit-unit ini
  • perubahan dalam proyek – setiap perubahan dalam proyek berpotensi berarti perubahan jumlah Poin Cerita yang diperlukan untuk mencapai Sasaran Produk. Mungkin juga tugas yang sudah selesai perlu dimodifikasi atau bahkan tidak digunakan dalam versi final Produk
  • kejadian tak terduga – memprediksi laju proyek masa depan berdasarkan yang sudah selesai, yaitu menerjemahkan Kecepatan aktual menjadi Kecepatan yang Direncanakan, dapat menghasilkan perkiraan yang akurat. Namun, setiap proyek memiliki kekhasan dan prediksi akurat berdasarkan sejarah biasanya tidak mungkin.
Velocity in Scrum

Ringkasan

Menggunakan Velocity sebagai metrik untuk mengevaluasi efektivitas Tim Pengembang dapat menyebabkan keandalannya menurun. Ini juga dapat menurunkan kualitas perkiraan, yang kami tulis secara lebih rinci di artikel ini. Lagi pula, untuk mendapatkan hasil terbaik dalam metrik, Tim Pengembang mungkin melebih-lebihkan intensitas tenaga kerja tugas untuk meningkatkan Kecepatan. Ini merugikan karena tim itu sendiri kemudian kehilangan informasi berharga untuk melakukan perbaikan dan merencanakan tugasnya dengan lebih akurat.

Kecepatan dalam Scrum sangat berguna terutama sebagai ukuran internal yang digunakan oleh Tim Pengembang untuk mengevaluasi kecepatan kerjanya. Ini karena memungkinkannya untuk menentukan berapa banyak tugas yang mampu diselesaikannya selama satu Sprint.

Kecepatan di tangan Pemilik Produk menjadi alat yang berguna untuk memperkirakan tenggat waktu untuk tugas yang lebih besar.

Namun, risiko terbesar terkait dengan penggunaan Velocity sebagai metrik untuk mengevaluasi Tim Pengembang. Hal ini karena hal ini dapat menyebabkan penurunan kredibilitasnya dan bahkan penilaian yang berlebihan dari nilainya untuk meningkatkan evaluasi eksternal dari pekerjaan Tim Scrum.

Jika Anda menyukai konten kami, bergabunglah dengan komunitas lebah sibuk kami di Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.

Scrum Guide | 34. Velocity in Scrum - Speed of the Development Team caroline becker avatar 1background

Pengarang: Caroline Becker

Sebagai Manajer Proyek, Caroline ahli dalam menemukan metode baru untuk merancang alur kerja terbaik dan mengoptimalkan proses. Keterampilan organisasi dan kemampuannya untuk bekerja di bawah tekanan waktu menjadikannya orang terbaik untuk mengubah proyek rumit menjadi kenyataan.

Lihat semua posting

Panduan Scrum:

  1. Daftar istilah dasar, peran dan pengertian
  2. Apa itu Scrum?
  3. Nilai scrum
  4. Bagaimana menerapkan Scrum di perusahaan Anda?
  5. Tim Scrum - apa itu dan bagaimana cara kerjanya?
  6. Siapa Pemilik Produk?
  7. Kesalahan paling umum dari Pemilik Produk
  8. Siapa Scrum Masternya?
  9. Karakteristik Scrum Master yang baik
  10. Kesalahan paling umum dari Scrum Master
  11. Statistik dan metrik apa yang harus dilacak oleh Scrum Master?
  12. Kerjasama antara Pemilik Produk dan Scrum Master
  13. Tim Pengembang di Scrum
  14. Kesalahan paling umum dari Pengembang
  15. Artefak scrum
  16. Scaling Scrum
  17. Sprint Backlog
  18. Apa itu Product Backlog?
  19. Apa itu Cerita Pengguna?
  20. Membuat Kisah Pengguna terbaik dengan INVEST
  21. Kesalahan Cerita Pengguna yang paling umum
  22. Kriteria Penerimaan Cerita Pengguna
  23. Estimasi dan Poin Cerita di Scrum
  24. Perencanaan Poker
  25. Game Estimasi Tim
  26. Mendefinisikan Kenaikan
  27. Acara Scrum
  28. Apa itu Sprint di Scrum?
  29. Komitmen Tim Scrum - Sasaran Produk, Sasaran Sprint, dan Definisi Penyelesaian
  30. Apa itu Grafik Burndown?
  31. Bagaimana cara membuat dan menafsirkan grafik burndown?
  32. Keuntungan dan kerugian dari grafik burndown
  33. Papan Kanban di Scrum dan Scrumban
  34. Kecepatan dalam Scrum - Kecepatan Tim Pengembang
  35. Scrum Harian
  36. Perencanaan Sprint
  37. Ulasan Sprint
  38. Apa itu Retrospektif Sprint?
  39. Kesalahan umum selama Sprint Retrospective
  40. Pemeliharaan Backlog Produk