Panduan Scrum | 11. Statistik dan metrik yang harus dilacak oleh Scrum Master

Diterbitkan: 2022-04-21

Mengapa Scrum Master membutuhkan statistik dan metrik? Pertama, untuk memeriksa apakah metode kerjanya dalam memprediksi hasil dan meningkatkan efektivitas tim sudah efektif. Tetapi juga untuk melacak bagaimana tindakan mereka mempengaruhi Tim Pengembang. Yaitu, bagaimana mereka membentuk pengalaman pengguna karyawan (UX). Jadi dalam artikel ini, kami memperkenalkan statistik dan metrik yang harus dilacak oleh Scrum Master.

Statistik dan metrik yang penting bagi master scrum – daftar isi:

  1. Mengukur hasil kerja Tim Pengembang
  2. Memantau pengalaman pengguna karyawan Pengembang
  3. Ringkasan

Mengukur hasil kerja Tim Pengembang

Statistik dan metrik yang paling umum digunakan yang harus dilacak oleh Scrum Master adalah statistik dan metrik yang menggambarkan kecepatan dan alur pelaksanaan tugas. Ini adalah Bagan Pembakaran, Bagan Pembakaran, dan Bagan Alir Kumulatif. Ini mengukur pengembangan produk dan efektivitas tim. Masing-masing memungkinkan Anda untuk mendekati masalah ini dari sudut yang berbeda, jadi ada baiknya untuk menunjukkannya bersama-sama. Mereka adalah alat yang berguna untuk menilai kemajuan pada skala yang berbeda, selama Sprint serta seluruh proses pengembangan produk.

Statistics and metrics

Bagan Pembakaran

Grafik burndown menunjukkan Scrum Master dan Tim Pengembang berapa banyak pekerjaan yang telah dilakukan dan berapa banyak yang tersisa untuk dilakukan. Sumbu X menunjukkan waktu yang tersisa untuk menyelesaikan pekerjaan. Sumbu Y menunjukkan jumlah pekerjaan yang tersisa untuk diselesaikan yang direncanakan dalam Sprint Backlog atau Product Backlog.

Bagan ini juga membantu menentukan Kecepatan Tim Pengembang, yang juga akan kami bahas dalam artikel terpisah. Di sini kami hanya akan menyebutkan bahwa ini adalah jumlah rata-rata pekerjaan yang dilakukan selama satu Sprint.

Alat sederhana ini memungkinkan Scrum Master untuk tidak hanya melihat seberapa efisien tim bekerja. Ini juga membantu untuk menjawab pertanyaan:

  • Bagian mana dari pekerjaan yang sudah selesai?
  • Berapa banyak tugas yang tersisa untuk diselesaikan?
  • Berapa lama waktu yang dibutuhkan untuk mengembangkan Produk?

Saat menggunakan Burndown Chart, Scrum Master perlu mengingat bahwa ini bukan satu-satunya alat untuk menilai kemajuan tim secara statistik. Ini bekerja paling baik untuk proyek-proyek di mana ruang lingkup pekerjaan tetap dan diketahui. Itu tidak berkinerja baik dengan menciptakan solusi yang sangat inovatif dengan Klien baru. Kemudian jumlah pekerjaan yang harus dilakukan di seluruh proyek – yang merupakan isi dari Product Backlog – dapat berubah secara signifikan selama proyek, sehingga sulit untuk menggunakan Burndown Chart.

Bagan pembakaran

Grafik Burnup adalah kebalikan dari grafik Burndown yang dibahas di atas. Di sini juga, sumbu Y menunjukkan jumlah pekerjaan yang tersisa untuk diselesaikan. Sumbu X, di sisi lain, menunjukkan waktu penyelesaian yang dinyatakan dalam jumlah Sprint atau tanggal.

Namun, Scrum Master menggunakan Burnup Chart untuk tujuan yang sedikit berbeda. Ini karena tidak hanya membantu Anda dalam mengukur kemajuan produk dan kemajuan Tim. Metrik ini juga menilai bagaimana ruang lingkup pekerjaan dalam suatu proyek berubah dari waktu ke waktu. Oleh karena itu, ini berfungsi dengan baik untuk proyek dengan cakupan variabel.

Burnup Chart juga merupakan alat perencanaan yang menjadi lebih efektif dari waktu ke waktu. Ini memberikan jawaban atas pertanyaan tentang berapa banyak pekerjaan yang diperkirakan akan dilakukan oleh Tim Pengembang di Sprint berikutnya.

Diagram Alur Kumulatif

Jenis diagram ketiga yang sangat bermanfaat dalam pekerjaan Scrum Master dengan Tim Pengembang adalah Diagram Alur Kumulatif. Ini menampilkan analisis tentang seberapa stabil kecepatan dan produktivitas Tim Pengembang. Tata letak sumbunya sama dengan Burnup Chart, sehingga sering disebut sebagai versi yang lebih kompleks.

Namun, Diagram Alir Kumulatif tidak hanya untuk menentukan jumlah tugas yang diselesaikan dalam jangka waktu tertentu. Ini juga memperhitungkan jumlah tugas yang menunggu dalam antrian untuk dieksekusi. Berkat ini, memungkinkan untuk mendiagnosis apa yang disebut "kemacetan" - momen proses yang memperlambat penciptaan suatu produk.

Fitur yang sangat diagnostik ini menjadikannya salah satu metrik paling berguna di tangan Scrum Master. Ini karena memungkinkan untuk mengatur ulang pekerjaan dengan cara mendistribusikan kekuatan Tim Pengembang secara berbeda dan menghindari waktu henti.

Statistics and metrics the Scrum Master should track

Memantau pengalaman pengguna karyawan Pengembang

Pemeliharaan dan analisis statistik yang teratur dan teliti adalah bagian penting dari pekerjaan Scrum Master yang efektif. Namun, ia harus terlebih dahulu mengingat pengalaman pengguna karyawan pengembang, yaitu cara mereka memandang pekerjaan di Tim Scrum. Namun, bukan kualitas metrik yang menentukan, tetapi cara Scrum Master menggunakannya.

Jika statistik disimpan sesuai dengan prinsip-prinsip Scrum – statistik tersebut transparan, publik, dan dapat dipahami oleh Pengembang yang terlibat – statistik tersebut dapat menjadi cara untuk memotivasi tim untuk bekerja lebih efisien atau sebagai penghargaan atas hasil yang luar biasa. Namun, statistik dapat berfungsi sebagai alat untuk menekan Tim Pengembang. Kemudian indikasi mereka menjadi generator tuduhan dan kebencian. Mereka dapat berkontribusi pada memburuknya moral tim dan merusak praktik kerja tim.

Faktor penting kedua dari pengalaman karyawan Pengembang, yang harus diperhatikan oleh Scrum Master dengan alat statistik, adalah cara mengatur waktu mereka. Ini karena Scrum Master perlu memiliki waktu yang cukup untuk mengurus Tim Pengembang. Untuk alasan ini, dalam kasus proyek besar, perlu dipertimbangkan untuk memasukkan orang tambahan ke dalam Tim Scrum. Dia akan bertindak sebagai manajer proyek dan akan mengurus metrik. Berkat ini, ini akan membebaskan Scrum Master – dan sampai batas tertentu Pemilik Produk – dari tugas-tugas yang mengalihkan perhatiannya dari bekerja dengan Tim Pengembang.

Statistik dan metrik – ringkasan

Scrum Master harus melacak statistik dasar yang menjelaskan pekerjaan Tim Pengembang. Interpretasi mereka yang terampil meningkatkan peluang untuk menemukan masalah dengan cepat dalam pekerjaan Tim dan bereaksi terhadapnya. Namun, yang lebih penting daripada menjaga grafik adalah apa yang dilakukan Scrum Master dengan mereka. Mereka seharusnya tidak memperlakukan metrik sebagai alat untuk mengevaluasi Tim, tetapi memperlakukannya sebagai bantuan yang berguna dalam memotivasi Tim dan mendiagnosis cara mereka sendiri dalam melakukan sesuatu. Ini karena metrik hanya akan menjadi alat yang berguna jika metrik membantu memfasilitasi Tim dan proses peningkatan Produk.

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

Scrum Guide | 11. Statistics and metrics the Scrum Master should track 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