Panduan Scrum | 40. Pemeliharaan Product Backlog

Perawatan Product Backlog adalah salah satu tugas utama dari seorang Product Owner. Proses perawatan mencakup merumuskan, merinci, dan menambahkan User Stories baru ke dalam Product Backlog. Namun, tugas perawatan yang paling penting adalah memastikan bahwa entri yang ditempatkan dalam Backlog berada dalam urutan yang benar, yaitu menjadi prioritas.

Perawatan Product Backlog – daftar isi:

1. Pendahuluan
2. Tujuan Perawatan Product Backlog
3. Kesalahan dalam pemeliharaan Product Backlog
4. Pemeliharaan Backlog vs. metrik yang digunakan dalam Scrum
5. Ringkasan

Pendahuluan

Product Backlog adalah salah satu Artefak Scrum. Ini berisi daftar pekerjaan yang diprioritaskan yang diperlukan untuk menciptakan sebuah Produk. Dengan kata lain, ini adalah daftar User Stories yang diperlukan untuk mencapai Tujuan Produk. Anda dapat menemukan deskripsi rinci tentang apa itu User Stories dalam artikel ini. Dan di sini adalah rincian tentang karakteristik dan cara memelihara Product Backlog.

Perawatan Product Backlog juga dikenal dengan nama-nama berikut:

• Prioritas Backlog,
• Penyempurnaan Backlog,
• Skala Backlog.

Tujuan Perawatan Product Backlog

Product Owner mengelola Product Backlog. Keterampilan kunci termasuk memprioritaskan tugas saat tenggat waktu mendekat. Ini karena tujuan dari perawatan Product Backlog adalah untuk memastikan bahwa fungsionalitas Produk datang dengan nilai bisnis tertinggi, yaitu yang paling penting dari sudut pandang Pelanggan, berada di bagian atas daftar tugas. Dan deskripsinya jelas dan rinci sehingga implementasinya dapat dimulai tepat di Sprint berikutnya.

Product Backlog dapat diperbarui setiap hari jika diperlukan. Product Owner dapat menambahkan User Stories baru ke dalam Product Backlog setelah berbicara dengan Pemangku Kepentingan dan Tim Pengembangan, atau dengan menarik kesimpulan dan merumuskan kembali User Stories yang sudah ditulis dalam 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, selama pertemuan ini, Tim Scrum membahas tidak hanya tugas yang harus diselesaikan di Sprint berikutnya. Ini juga secara preliminer menentukan User Stories dan implementasinya dalam dua atau tiga Sprint berikutnya. Cara melakukan hal ini memungkinkan Tim Scrum dan aktivitasnya untuk mengambil pandangan yang lebih luas tentang arah jangka panjang. Ini memungkinkan untuk memikirkan tugas yang sedang dilakukan saat ini dari perspektif pengembangannya di Sprint berikutnya.

Kesalahan dalam pemeliharaan Product Backlog

Salah satu masalah yang paling umum terkait dengan perawatan Product Backlog adalah memberikannya ruang untuk berkembang tanpa kendali. Ini karena saat bekerja pada Produk, berbagai fungsionalitas tambahan dan tugas yang diusulkan oleh Pemangku Kepentingan dan anggota Tim Scrum muncul secara spontan. Oleh karena itu, membatasi pertumbuhan ruang lingkup Product Backlog (scope creep) adalah salah satu tugas terpenting yang dilakukan oleh Product Owner. Kesalahan yang paling umum yang dilakukan oleh Product Owner berkaitan dengan:

1. Menjauh dari Tujuan Produk – menambahkan terlalu banyak ide ke dalam Product Backlog di luar Tujuan Produk dasar bukanlah praktik yang baik, karena sangat mengurangi keterbacaan. Lebih baik mengumpulkan ide untuk fungsionalitas tambahan dalam dokumen terpisah.
2. Duplikasi konten – memasukkan ide yang diulang atau sangat mirip dari berbagai Pemangku Kepentingan ke dalam Backlog – sebelum menambahkan entri lain ke dalam Backlog, Product Owner harus memastikan bahwa entri baru tidak menduplikasi salah satu entri yang sudah ada.
3. Kekurangan perspektif yang lebih luas – Anda harus mengurutkan entri Product Backlog sesuai dengan nilainya terkait dengan Tujuan Produk. Namun, ingatlah bahwa pemprioritasan harus mempertimbangkan beberapa Sprint berikutnya sehingga tugas yang dilakukan dalam Sprint tertentu terhubung dengan mulus baik ke Sprint sebelumnya maupun Sprint yang segera mengikutinya.

Anda tidak dapat menghindari kesalahan semacam ini. Namun, kesadaran akan terjadinya kesalahan ini dapat membuat Product Owner lebih berhati-hati dalam menambahkan User Stories baru ke dalam Product Backlog untuk mencapai keseimbangan yang tepat. Ini karena juga merupakan kesalahan memberikan Backlog terlalu banyak pemotongan dan menghilangkan entri yang berisi tugas serupa yang berbeda. Misalnya, mendeskripsikan fungsionalitas Produk yang serupa tetapi berbeda secara signifikan dalam penerapannya.

Pemeliharaan Backlog vs. metrik yang digunakan dalam Scrum

Product Backlog berisi deskripsi tentang sisa pekerjaan sepanjang proyek. Namun, hanya Backlog yang diperbarui dan dipelihara secara teratur yang dapat memperkirakan dengan akurat rasio jumlah pekerjaan yang diselesaikan terhadap total. Untuk menggambarkan jumlah pekerjaan yang diselesaikan, Anda harus menerapkan Burndown Chart, yang telah kami tulis dalam artikel ini.

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

Ringkasan

Product Owner melakukan Perawatan Product Backlog. Ketika Product Backlog dikelola dengan baik, Tim Scrum memiliki pandangan yang jelas tentang pekerjaan yang tersisa. Ini juga dapat memberikan perspektif yang lebih luas dan ke depan tentang bagaimana jalannya menuju Tujuan Produk. Inilah sebabnya mengapa Product Owner perlu memastikan bahwa User Stories yang termasuk dalam Product Backlog berada dalam urutan prioritas untuk diselesaikan. Dan juga bahwa tugas yang harus diselesaikan dalam Sprint yang akan datang dijelaskan dengan detail yang sangat baik.

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