---

Apa itu Scrum Product Backlog? Jawabannya Mungkin Mengejutkan Anda!

Product Backlog (Scrum Backlog) atau Scrum Product Backlog adalah unsur utama pengelolaan seluruh persyaratan produk Scrum yang diketahui.

Isinya adalah pekerjaan terurut yang terus muncul untuk meningkatkan produk serta mencapai tujuannya. Persyaratan mencakup kebutuhan fungsional serta nonfungsional dan fitur lain terkait pengalaman pengguna serta desain antarmuka.

Product Backlog berisi permintaan fitur serta cerita pengguna tingkat tinggi. Ini juga dapat mencakup prasyarat atau persyaratan pelengkap proyek, seperti pembangunan lingkungan pengujian dan pengembangan. Cerita pengguna untuk memperbaiki bug yang diketahui, mengurangi utang teknis, atau meningkatkan fitur juga termasuk di dalamnya.

Setiap produk memiliki satu Product Backlog bersama seluruh Scrum Team yang mengerjakannya. Scrum Product Owner bertanggung jawab atas pembuatan, pemeliharaan, serta penyempurnaannya. Product Backlog tidak menjawab dan tidak seharusnya menjawab cara persyaratan dikembangkan serta disampaikan.

Itulah tugas Scrum Team. Tim menentukan dan mendokumentasikan tugas yang diperlukan untuk memenuhi persyaratan dalam Sprint Backlog. Product Backlog dan Sprint Backlog adalah entitas yang terpisah secara fisik, walaupun item Product Backlog menentukan isi Sprint Backlog.

Pemilik Scrum Product Backlog adalah Scrum Product Owner. Scrum Master, Scrum Team, dan pemangku kepentingan lain berkontribusi menyusun daftar cerita pengguna yang lebih luas demi keberhasilan produk.

Penggunaan Scrum Product Backlog tidak melarang tim membuat serta menggunakan artefak lain untuk mengelola pekerjaan. Contohnya ringkasan peran pengguna, uraian alur kerja, panduan antarmuka, papan cerita, atau prototipe antarmuka. Artefak ini melengkapi serta memerinci isi Scrum Product Backlog, bukan menggantikannya.

Product Backlog adalah dokumen yang hidup. Seperti perangkat lunak yang meningkat bertahap, Product Backlog juga berkembang seiring waktu. Kerangka kerja Scrum tidak memerlukan proses pengelolaan perubahan tersendiri. Scrum Product Owner membuat versi awal Product Backlog berdasarkan pemahaman awal terbaiknya tentang produk.

Sambil mengamati perkembangan produk antar-Sprint dan memperoleh pengetahuan tambahan tentang kebutuhan klien, Scrum Product Owner menambah, menghapus, serta menyempurnakan persyaratan dalam Product Backlog.

Scrum Product Owner memprioritaskan persyaratan dalam Product Backlog. Semakin tinggi prioritas item, semakin terperinci isinya. Dengan demikian, tim mudah memahami persyaratan berprioritas tinggi dan membuat tugas yang diperlukan untuk membangunnya.

Developers menentukan ukuran item Product Backlog sesuai kebutuhan; poin cerita adalah salah satu teknik opsional. Estimasi perlu disempurnakan bagi cerita berprioritas tinggi agar siap untuk Sprint Planning.

Setiap Scrum Product Backlog memiliki atribut khusus yang membedakannya dari daftar tugas sederhana:

• Cerita pengguna selalu menambah nilai bisnis atau teknis bagi klien, pemilik bisnis, serta pengguna akhir,
• Seluruh cerita pengguna diprioritaskan dan diurutkan dari prioritas tertinggi hingga terendah,
• Tingkat detail cerita pengguna bergantung pada posisinya dalam Scrum Product Backlog,
• Cerita pengguna ditentukan ukurannya sesuai kebutuhan dengan teknik yang sesuai,
• Scrum Product Backlog adalah dokumen yang hidup,
• Product Backlog menjelaskan pekerjaan produk; rencana pelaksanaan terperinci Developers berada dalam Sprint Backlog.

Cerita Pengguna Menambah Nilai bagi Klien, Bisnis, dan Sistem

Setiap cerita pengguna Scrum Product Backlog harus menawarkan nilai bagi klien. Cerita tanpa nilai klien merupakan pemborosan sumber daya murni dan perlu dihapus. Scrum Product Backlog dapat mencakup cerita pengguna untuk:

• Spesifikasi persyaratan fungsional dan nonfungsional,
• Ringkasan pemecahan tingkat tinggi pekerjaan yang diperlukan untuk meluncurkan produk perangkat lunak,
• Penyiapan lingkungan pengembangan dan peragaan nonproduksi,
• Perbaikan cacat.

Contoh Scrum Product Backlog

Sebagian tugas mungkin tidak langsung menambah nilai fungsi sistem atau klien bisnis. Namun, tugas harus menambah nilai melalui peningkatan kualitas, pengurangan utang teknis, dan peningkatan kemudahan pemeliharaan produk dalam jangka panjang.

Product Backlog adalah Dokumen yang Hidup

Scrum Product Backlog adalah dokumen hidup yang berubah serta berkembang sepanjang proyek. Bila perlu, cerita baru ditambahkan; cerita yang ada dapat diubah, diperinci, atau dihapus. Persyaratan proyek Scrum tidak lagi dibekukan sejak awal seperti dalam Metodologi Waterfall.

Sebaliknya, kumpulan akhir persyaratan dikembangkan secara berulang bersama Increment perangkat lunak yang muncul.

Ini berbeda dari rekayasa persyaratan tradisional. Cara baru menangani kebutuhan klien membantu tim memaksimalkan nilai klien dan meminimalkan pemborosan sumber daya.

Tingkat Detail Berbeda

Persyaratan Scrum Product Backlog dapat memiliki kedalaman detail yang berbeda. Hanya persyaratan yang akan diimplementasikan dalam beberapa Sprint berikutnya yang perlu diperinci lebih mendalam. Cerita lain sebaiknya tetap umum dan baru diproses "tepat pada waktunya" sebelum tim perlu mengetahuinya lebih jauh.

Menginvestasikan waktu serta sumber daya untuk memerinci persyaratan tersebut tidak masuk akal karena sebagian mungkin berubah atau hilang sebelum diperlukan untuk implementasi. Penanganan persyaratan "tepat pada waktunya" merupakan salah satu manfaat terbaik Scrum untuk menghadapi "hal yang belum diketahui keberadaannya" dalam proyek Anda.

Tidak Ada Tugas Tingkat Rendah dalam Product Backlog

Product Backlog biasanya menjelaskan pekerjaan produk, bukan pemecahan tugas terperinci untuk menjalankannya. Scrum Product Owner menetapkan persyaratan bersama klien bisnis serta pemangku kepentingan sebelum membawanya ke Refinement Backlog atau Sprint Planning. Developers bertanggung jawab memecah tugas secara terperinci dan mengorganisasi pekerjaannya sendiri.

Scrum Product Backlog Diurutkan berdasarkan Prioritas

Seluruh cerita pengguna diprioritaskan, dan Scrum Product Backlog diurutkan dari prioritas tertinggi hingga terendah. Scrum Product Owner memprioritaskan dengan dukungan Scrum Team. Nilai tambah bagi bisnis klien, biaya, risiko, serta ketergantungan merupakan faktor yang paling umum dipertimbangkan. Prioritas ini membantu Product Owner menentukan pekerjaan yang selanjutnya dibangun dan disampaikan tim.

Memberi Ukuran Item Product Backlog

Developers dapat menentukan ukuran item dengan teknik yang disepakati, seperti poin cerita berskala Fibonacci atau ukuran relatif S/M/L/XL/XXL. Scrum tidak mewajibkan satu skala atau estimasi setiap item yang masih jauh. Hal ini dibahas lebih lanjut nanti. Estimasi memengaruhi perencanaan kapasitas Sprint, isi Sprint Backlog, dan rencana rilis.

Bekerja dengan Backlog

Scrum Product Backlog memerlukan perawatan serta perhatian rutin. Backlog harus dikelola cermat karena merupakan sumber kebenaran untuk memahami keseluruhan produk perangkat lunak Anda.

Pada awal proyek, isinya banyak cerita tingkat tinggi yang mungkin sangat relevan atau tidak bagi keberhasilan proyek. Seiring kemajuan antar-Sprint, Scrum Product Owner serta tim semakin memahami proyek.

Isi Scrum Product Backlog kemudian semakin mencerminkan produk serta pembelajaran tim.

Setelah penyiapan awal, Scrum Product Backlog harus terus dipelihara. Pemeliharaan ini berarti:

• Persyaratan baru yang ditemukan dijelaskan serta ditambahkan. Persyaratan lama dapat diubah atau dihapus sesuai kebutuhan,
• Mengurutkan (Memprioritaskan) Scrum Product Backlog. Cerita terpenting (prioritas tertinggi) dipindahkan ke atas,
• Menyiapkan cerita berprioritas tinggi untuk Sprint Planning mendatang (biasanya dalam Refinement Backlog),
• Mengestimasi (Ulang) cerita pengguna dalam Scrum Product Backlog (biasanya dalam Refinement Backlog).

Scrum Product Owner bertanggung jawab memastikan Scrum Product Backlog selalu dalam kondisi baik. Namun, pemeliharaannya merupakan proses kolaboratif. Kapasitas anggota yang wajar perlu disediakan untuk refinement Product Backlog berkelanjutan serta waktu bagi acara Scrum.

Pemeliharaan kolaboratif ini juga memperjelas persyaratan dan membangun dukungan anggota terhadap produk perangkat lunak yang berkembang.