Panduan Scrum | 40. Pemeliharaan Backlog Produk

Diterbitkan: 2022-07-21

Pemeliharaan Product Backlog adalah salah satu tugas utama Pemilik Produk. Proses pengasuhan termasuk merumuskan, merinci dan menambahkan Cerita Pengguna baru ke Product Backlog. Namun, tugas pengasuhan yang paling penting adalah memastikan bahwa entri yang ditempatkan di Backlog berada dalam urutan yang benar, yaitu diprioritaskan.

Pemeliharaan Product Backlog – daftar isi:

  1. pengantar
  2. Tujuan pemeliharaan Product Backlog
  3. Kesalahan dalam pemeliharaan Product Backlog
  4. Pemeliharaan backlog vs. metrik yang digunakan di Scrum
  5. Ringkasan

pengantar

Product Backlog adalah salah satu Artefak Scrum. Ini berisi daftar prioritas pekerjaan yang diperlukan untuk membuat Produk. Dengan kata lain, ini adalah daftar Kisah Pengguna yang diperlukan untuk mencapai Sasaran Produk. Anda dapat menemukan deskripsi terperinci tentang apa itu Cerita Pengguna di artikel ini. Dan berikut adalah rincian ciri-ciri dan cara menjaga Product Backlog.

Pemeliharaan Product Backlog juga dikenal dengan nama berikut:

  • Prioritas Backlog,
  • Penyempurnaan Backlog,
  • Penskalaan Backlog.

Tujuan pemeliharaan Product Backlog

Product Owner mengelola Product Backlog. Keterampilan utama termasuk memprioritaskan tugas sebagai pendekatan tanggal jatuh tempo mereka. Hal ini karena tujuan pemeliharaan Product Backlog adalah untuk memastikan bahwa fungsionalitas Produk memiliki nilai bisnis tertinggi, yaitu yang paling penting dari sudut pandang Pelanggan, berada di urutan teratas daftar tugas. Dan deskripsi mereka jelas dan detail sehingga implementasinya bisa dimulai tepat di Sprint berikutnya.

Product Backlog dapat diperbarui setiap hari jika diperlukan. Product Owner dapat menambahkan User Stories baru ke Product Backlog setelah berbicara dengan Stakeholder dan Tim Pengembang, atau dengan menarik kesimpulan dan merumuskan kembali User Stories yang sudah tertulis di Product Backlog.

Pembaruan wajib dari Backlog adalah salah satu tugas yang dilakukan selama Sprint Review. Kami menjelaskan proses itu secara rinci dalam artikel ini. Biasanya, dalam pertemuan ini, Tim Scrum tidak hanya membahas tugas-tugas yang harus diselesaikan di Sprint berikutnya. Ini juga terlebih dahulu menentukan Cerita Pengguna dan implementasinya dalam dua atau tiga Sprint berikutnya. Cara melakukan sesuatu ini memungkinkan Tim Scrum dan aktivitasnya untuk mengambil pandangan yang lebih luas tentang arah jangka panjang. Hal ini memungkinkan untuk memikirkan tugas yang sedang dilakukan dari perspektif perkembangan mereka di Sprint berikutnya.

product backlog nurturing

Kesalahan dalam pemeliharaan Product Backlog

Salah satu masalah paling umum mengenai pemeliharaan Product Backlog adalah membiarkannya berkembang tak terkendali. Hal ini karena saat mengerjakan Produk, berbagai fungsi dan tugas tambahan yang diajukan oleh Pemangku Kepentingan dan anggota Tim Scrum muncul secara spontan. Oleh karena itu, membatasi pertumbuhan cakupan Product Backlog (scope creep) adalah salah satu tugas terpenting yang dilakukan oleh Pemilik Produk. Kesalahan paling umum yang dilakukan Pemilik Produk:

  1. Menyimpang dari Tujuan Produk – menambahkan terlalu banyak ide ke Product Backlog di luar Tujuan Produk dasar bukanlah praktik yang baik, karena sangat mengurangi keterbacaannya. Ini berfungsi lebih baik untuk mengumpulkan ide untuk fungsionalitas tambahan dalam dokumen terpisah.
  2. Duplikasi konten – memasukkan ide yang berulang atau sangat mirip dari Pemangku Kepentingan yang berbeda ke dalam Backlog – sebelum menambahkan entri lain ke Backlog, Pemilik Produk harus memastikan bahwa entri baru tidak menduplikasi entri yang sudah ada.
  3. Kurangnya perspektif yang lebih luas – Anda harus memesan entri Product Backlog sesuai dengan nilainya mengenai Sasaran Produk. Namun, perlu diingat bahwa prioritas harus mempertimbangkan beberapa Sprint berikutnya sehingga tugas yang dilakukan dalam Sprint tertentu terhubung dengan mulus ke Sprint sebelumnya dan Sprint segera setelahnya.

Anda tidak dapat menghindari kesalahan semacam ini. Namun, kesadaran akan kemunculannya dapat membuat Pemilik Produk lebih berhati-hati dalam menambahkan Cerita Pengguna baru ke Product Backlog untuk mencapai keseimbangan yang tepat. Hal ini karena juga merupakan kesalahan untuk memberikan Backlog terlalu banyak memotong dan menghilangkan entri yang berisi tugas serupa yang berbeda. Misalnya, menjelaskan fungsionalitas Produk serupa yang berbeda secara signifikan dalam aplikasi.

Pemeliharaan backlog vs. metrik yang digunakan di Scrum

Product Backlog berisi deskripsi pekerjaan yang tersisa di seluruh proyek. Namun, hanya Backlog yang up-to-date dan dipelihara secara teratur yang dapat secara akurat memperkirakan rasio jumlah pekerjaan yang diselesaikan terhadap total. Untuk menggambarkan jumlah pekerjaan yang diselesaikan, Anda harus menerapkan Burndown Chart, yang kami tulis di artikel ini.

Metrik populer lainnya untuk menggambarkan kerja Tim Scrum adalah Velocity. Anda dapat mengukurnya dengan membandingkan jumlah entri Product Backlog yang diubah menjadi Increment selama satu Sprint. Kami menjelaskan Velocity secara lebih rinci dalam artikel ini.

Product Backlog nurturing

Ringkasan

Product Owner melakukan Product Backlog Nurturing. Ketika Product Backlog terpelihara dengan baik, Tim Scrum memiliki pandangan yang jelas tentang pekerjaan yang tersisa. Itu juga bisa mendapatkan perspektif yang lebih luas dan berwawasan ke depan tentang seperti apa jalan menuju Sasaran Produk. Inilah sebabnya mengapa Pemilik Produk perlu memastikan bahwa Cerita Pengguna yang termasuk dalam Product Backlog berada dalam urutan prioritas untuk diselesaikan. Dan juga bahwa tugas yang harus diselesaikan dalam Sprint mendatang dijelaskan dengan detail terbaik.

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

Scrum Guide | 40. Product Backlog nurturing 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