Menyusun Product Backlog Item dan Estimasi Bobot

Tanpa product backlog yang tepat, tujuan pengembangan produk akan sulit tercapai. Semua stakeholder, terutama Product Owner perlu memiliki pemahaman yang cukup agar dapat memaksimalkan nilai bisnis secara efektif. Artikel ini membahas langkah konkrit dalam menyusun product backlog mulai dari penentuan product goal hingga terbentuknya product backlog item. Langkah-langkah ini merupakan pengalaman praktis kami, sedangkan untuk acuan dasar dapat merujuk pada Scrum Guide di scrumguides.org.

Product Backlog adalah daftar yang berisi urutan dari hal-hal yang perlu dikerjakan untuk meningkatkan nilai (value) dari suatu produk. Daftar ini dapat terus berkembang dan menjadi satu-satunya acuan pekerjaan bagi Scrum Team. (Scrum.org)

Ada 5 langkah yang perlu dilakukan, yaitu:

1. Menentukan Product Goal
2. Membuat Product Backlog Item
3. Menentukan Urutan Prioritas
4. Menentukan Bobot PBI
5. Menentukan Sprint Velocity

Langkah 1 : Menentukan Product Goal

Untuk dapat menyusun product backlog, Product Owner harus terlebih dahulu memahami business needs atau product goal yang ingin dicapai. Untuk itu, Product Owner harus terlebih dahulu memahami kebutuhan para stakeholder dengan:

1. Menentukan masalah yang akan diselesaikan oleh product (problem to be solved).
2. Mengajukan solusi untuk menyelesaikan masalah tersebut (proposed solution).
3. Menentukan kriteria untuk mengukur kesuksesan solusi yang dibuat (success indicator).

1.Problem to be solved

Pada dasarnya, product atau aplikasi dibangun untuk menyelesaikan masalah yang dihadapi oleh organisasi. Product juga bisa dibuat untuk meraih suatu peluang, yang kalau tidak tercapai menimbulkan masalah, yaitu opportunity-loss. Oleh karenanya, hal pertama yang harus dilakukan adalah memahami masalah apa yang dihadapi para stakeholder.

Contohnya, pada proses checkout barang di toko serba-ada. Dalam sehari, banyak pelanggan yang datang dengan ekspektasi dapat berbelanja dengan mudah dan cepat. Namun, banyaknya pembeli dan variasi barang yang dijual bisa meningkatkan resiko salah perhitungan dan lambatnya proses checkout.

Masalah akan memunculkan risiko bagi organisasi. Setiap risiko dapat dinilai dengan menentukan severity dan likelihood dari risiko tersebut. Severity (impact) adalah dampak yang terjadi jika masalah tersebut tidak diselesaikan. Likelihood (probability) adalah seberapa besar kemungkinan masalah tersebut akan terjadi. Dampak lamanya checkout dan adanya kesalahan perhitungan adalah munculnya keluhan dari pembeli. Keluhan ini dapat mengakibatkan berkurangnya pembeli dan menurunnya pendapatan. Kemungkinan terjadinya sangat besar, karena checkout merupakan bagian dari inti proses bisnis. Dengan dampak (severity) dan kemungkinan (likelihood) yang besar, maka masalah ini harus diprioritaskan dan dicarikan solusinya.

Simple risk assessment matrix (Sumber: stakeholdermap.com)

2. Proposed Solution (hypothesis)

Solusi yang diajukan untuk menyelesaikan masalah yang dihadapi pada tahapan ini masih berupa hipotesis, karena belum pasti dapat menyelesaikannya. Setiap solusi memiliki beberapa faktor utama yang (Critical Success Factor) yang menentukan berhasil atau tidaknya penyelesaikan suatu masalah.

Pada contoh di atas, salah satu solusi yang bisa diajukan adalah dengan membangun sistem pemindaian (scan) barang secara cepat dan akurat. Tujuannya, identifikasi barang dan perhitungan total biaya dilakukan secara otomatis. Dimana salah satu CSF-nya adalah data barang-barang harus terdaftar secara akurat di sistem.

3. Success Indicator (Key Measurement)

Solusi harus memiliki success indicator agar kita dapat mengukur apakah masalah dapat diselesaikan dengan baik atau tidak. Indikator dapat berupa nilai kuantitatif ataupun kualitatif. Namun, disarankan untuk memakai indikator kuantitatif agar hasilnya dapat diukur dengan tepat. Indikator kualitatif sering kali menimbulkan perdebatan dikalangan stakeholder karena sifatnya yang relatif.

Contoh untuk solusi yang diajukan di poin sebelumnya, dapat diberikan success indicator: “Proses scan berlangsung kurang dari 1 detik dan kalkulasi harga total kurang dari 2 detik”.

Tahapan untuk menentukan product goal ini harus dilakukan berurutan. Mulai dari penentuan problem, lalu solution, kemudian baru penentuan success indicator. Tahapan ini juga perlu dilakukan secara iteratif untuk melengkapi problem, solution, maupun success indicatornya.

Langkah 2 : Membuat Product Backlog Item (PBI)

Setelah selesai menentukan problem, solution, dan success indicator, barulah Product Owner bisa menentukan backlog yang akan dikerjakan. Untuk membuat backlog, perlu dipahami terlebih dahulu komponen yang membentuk sebuah PBI dan kriteria yang harus dimiliki.

Komponen PBI

Berikut adalah komponen yang dimiliki oleh PBI sederhana.

Komponen Product Backlog Item

1. PBI Number

Masing-masing PBI harus memiliki identifier yang unik. Number ini berfungsi sebagai pembeda antara satu PBI dengan PBI lainnya. Selain itu, PBI number juga dapat dipakai untuk mempermudah tracking dan tracing PBI.

2. Backlog Item Description

Cara membuat deskripsi dari sebuah PBI dapat berbeda, tergantung dengan tipe backlog tersebut. Tipe backlog yang paling sering dipakai adalah functional backlog, architectural backlog, dan technical debt.

• Functional Backlog

Backlog ini menjelaskan kebutuhan proses bisnis secara langsung. Salah satu cara mendeskripsikan functional backlog adalah dengan menggunakan user story. User story terdiri dari 3 komponen yakni 1) Who — aktor yang melakukan aksi, 2) What — aksi atau hal yang dilakukan, dan 3) Why — dampak dari aksi yang dilakukan.

Contoh: Sebagai kasir, saya dapat memindai (scan) barang, sehingga kode dan harga barang teridentifikasi secara cepat dan akurat.

• Architectural Backlog

Backlog ini menjelaskan kebutuhan teknis untuk menunjang sistem. Architectural backlog dapat dijelaskan menggunakan kalimat singkat dan jelas (straight sentences).

Contoh: Upgrade aplikasi RDBMS ke versi terbaru.

• Technical Debt

Technical debt adalah pekerjaan yang muncul akibat kualitas pekerjaan yang buruk (Wikipedia). Pada prakteknya, hal ini sering terjadi setelah product dipakai di production. Akibatnya, technical debt seringkali memiliki prioritas tertinggi dari backlog tipe lainnya. Terutama saat hal itu menjadi show-stopper. Technical debt dapat dijelaskan menggunakan kalimat singkat dan jelas.

Contoh: Error ketika scan barang dengan jenis yang sama jika dilakukan berurutan.

3. Business Value

Business value adalah manfaat yang akan didapatkan oleh organisasi apabila solusi berhasil diimplementasi. Untuk menentukan business value dari sebuah backlog, Product Owner bisa menggunakan metode relative estimation. Relative estimation dapat dilakukan dengan membandingkan antara satu backlog dengan backlog lainnya, untuk menentukan mana backlog yang business value nya lebih tinggi. Contoh penentuan business value dapat dilhat pada langkah 3 mengenai penentuan urutan prioritas backlog.

4. Weight

Jika komponen sebelumnya ditentukan oleh Product Owner, komponen weight atau bobot ini ditentukan oleh development team. Dalam proses penentuan bobot, Product Owner menjelaskan masing-masing backlog kepada development team berikut dengan acceptance criteria untuk masing-masing backlog. Cara menentukan estimasi dapat dilihat pada langkah 4 mengenai estimasi bobot.

Kriteria PBI

Dalam pembuatan PBI, ada kriteria yang harus dipenuhi oleh masing-masing backlog. Kriteria tersebut adalah Independent, Negotiable, Valuable, Estimable, Small, Testable atau bisa disingkat INVEST.

Kriteria Product Backlog

• Independent: Suatu backlog tidak boleh bergantung pada backlog lainnya. Backlog harus bisa di implementasi tanpa menunggu backlog lainnya selesai. Tetapi jika dependensi antar backlog tidak dapat dihindari, dependensi ini harus dijadikan pertimbangan pada saat menentukan urutan backlog. Karena dependensi antar backlog akan berpengaruh besar pada urutan pengerjaannya.
• Negotiable: Suatu backlog tidak boleh terlalu detail sehingga menjadi kaku. Backlog tidak perlu mendeskripsikan cara atau langkah detail untuk mengimplementasikannya. Hal ini dikarenakan cara atau langkah tersebut bisa saja berubah ketika implementasi sedang dilakukan.
• Valuable: Suatu backlog harus memiliki value atau manfaat bagi stakeholder jika sudah berhasil diimplementasikan.
• Estimable: Sebuah backlog harus dapat diperkirakan bobotnya oleh development team.
• Small: Suatu backlog harus dapat dipahami sehingga bisa diuraikan (breakdown) menjadi task. Pada prakteknya, sebaiknya satu backlog dapat diselesaikan dalam satu sprint.
• Testable: Suatu backlog harus dapat diuji (test). Suatu backlog dapat dikatakan selesai jika sudah memenuhi kriteria yang ditentukan dengan jelas. Kriteria ini nantinya akan dituangkan dalam test scenario.

Langkah 3: Menentukan Urutan Prioritas Backlog

Urutan backlog dapat ditentukan dengan melihat business value dari masing-masing backlog. PBI akan diurutkan mulai dari yang memiliki business value tertinggi ke yang terendah, lalu eksekusi backlog dilakukan berurutan dari atas ke bawah.

Sebagai contoh, ada dua backlog sebagai berikut:

• PBI-001: Upgrade server ke versi terbaru
• PBI-002: Enhance tampilan aplikasi agar lebih rapi

PBI-001 memberikan manfaat bisnis secara langsung, karena proses load data yang lebih cepat akan meningkatkan pendapatan. Sedangkan PBI-002 membuat aplikasi lebih user friendly, namun tidak mempengaruhi pendapatan. Dari analisa manfaat tersebut, disimpulkan PBI-001 memiliki value lebih tinggi daripada PBI-002. Maka jika PBI-001 memiliki business value 10, PBI-002 akan memiliki business value lebih rendah, yakni 1.

Contoh product backlog untuk pengembangan sistem kasir toko serba-ada:

Product Backlog Item Toko Serba-ada

Langkah 4: Menentukan Estimasi PBI

Sebelum mulai melakukan estimasi backlog, development team harus memahami hal-hal yang dapat memengaruhi besarnya bobot suatu backlog. Penentuan bobot suatu backlog akan dipengaruhi oleh 3 hal, yakni:

• Size

Size menunjukkan ukuran dari pekerjaan yang akan dilakukan dalam implementasi backlog. Meskipun pekerjaannya tergolong mudah, jika ukuran pekerjaannya besar maka bobot pekerjaan bisa menjadi besar juga. Bayangkan jika ada backlog untuk merubah layout dari report yang ada di aplikasi. Pekerjaannya sendiri tergolong sederhana, namun ternyata ada lebih dari 100 report di aplikasi tersebut. Sehingga bobot backlog menjadi lebih besar dibanding jika hanya ada 10 report.

• Complexity

Complexity menunjukkan tingkat kesulitan dari pekerjaan yang akan dilakukan dalam implementasi backlog. Misal dalam pengerjaan backlog, harus ditentukan total harga dari semua barang. Bobot pekerjaan jika formula hanya berupa penjumlahan biasa, dibandingkan jika formulanya menghitung jumlah diskon terhadap harga dan poin keanggotaan akan berbeda. Tentu saja bobot akan lebih besar jika formula yang dipakai lebih kompleks.

• Uncertainty

Uncertainty menunjukkan tingkat ketidakpastian yang dimiliki sebuah backlog. Semakin tinggi ketidakpastian suatu backlog, semakin besar pula bobotnya. Contohnya jika backlog yang harus dikerjakan menuntut development team untuk menggunakan API dari third party yang masih dalam proses development. Bobot pekerjaan bisa saja bertambah besar karena belum dapat dipastikan API yang akan dipakai seperti apa, dan proses testing yang berpotensi harus dilakukan berkali-kali karena akan melibatkan third party yang jadwalnya sulit diperkirakan.

Setelah memahami 3 hal diatas, development team dapat mulai melakukan estimasi bobot backlog. Mekanisme dari estimasi bobot backlog adalah sebagai berikut:

1. Product Owner menjelaskan masing-masing backlog ke development team berikut dengan acceptance criteria backlog tersebut. Acceptance criteria adalah hal yang yang harus dicapai backlog, dimana hal ini akan berbeda untuk masing-masing backlog. Perlu digaris bawahi bahwa acceptance criteria berbeda dengan definition of done. Acceptance criteria adalah hal yang harus dicapai oleh masing-masing backlog, sedangkan definition of done adalah hal yang harus dicapai oleh semua backlog.
2. Development team menentukan bobot masing-masing backlog secara individual. Penentuan bobot ini bisa dilakukan dengan planning poker.
3. Jika terdapat perbedaan besar dari bobot yang diberikan oleh masing-masing anggota development team, maka development team bisa meminta kepada Product Owner untuk menjelaskan kembali backlog tersebut secara detail. Jika perbedaan bobot yang diberikan masing-masing anggota development team tidak besar, bisa dilakukan diskusi untuk menentukan berapa bobot yang akan ditetapkan untuk backlog tersebut.

Weight atau bobot backlog biasanya menggunakan fibonacci number. Fibonacci number dimulai dari 1, 2, 3, 5, 8, 13, dst. Hal ini karena pada fibonacci number, semakin besar angkanya akan semakin besar juga jarak dengan angka selanjutnya, sehingga sesuai dengan proporsi resikonya.

Contoh PBI Toko Serba-ada setelah ditentukan urutan dan estimasi weight.

Product Backlog Item Toko Serba-ada (dengan estimasi bobot)

Pada saat penentuan sprint backlog, bobot dari masing-masing backlog bisa saja berubah jika ditemukan similarity antar backlog dan backlog tersebut dikerjakan bersamaan pada satu sprint. Contoh terdapat 3 backlog mengenai pengolahan master data, yang jika di implementasi satu per satu akan membutuhkan bobot sebesar 5 poin untuk masing-masing backlog. Sedangkan jika dilakukan bersamaan dalam satu sprint, dapat dikurangi menjadi 3 poin masing-masing backlog karena dapat dilakukan copy and paste pada method yang digunakan.

Langkah 5 : Menentukan Sprint Velocity

Setelah Product Owner membuat PBI, dan development team membuat estimasi bobot untuk masing-masing backlog, proses selanjutnya adalah menentukan velocity untuk satu sprint.

Velocity adalah ukuran jumlah pekerjaan yang dapat dilakukan dan diselesaikan oleh development team dalam jangka waktu satu sprint (Scrum.org)

Berikut adalah tahapan untuk menentukan sprint velocity.

1. Tentukan total weight dari semua backlog yang ada pada daftar.
2. Tentukan sprint duration. Sprint duration adalah jangka waktu untuk menyelesaikan satu sprint. Misal, sprint duration untuk satu sprint 10 hari kerja.
3. Tentukan squad capacity. Untuk menentukan squad capacity, development team melakukan diskusi untuk menjawab pertanyaan “Dari seluruh backlog, dengan durasi satu sprint, team mampu menyelesaikan PBI dari nomor 1 sampai nomor berapa?”. Squad capacity adalah jumlah weight dari PBI yang bisa diselesaikan dalam satu sprint. Masing-masing anggota bisa saja memberikan jawaban yang berbeda. Jika hal itu terjadi, maka dapat diambil rata-rata dari total weight. Misal dari hasil diskusi, diketahui anggota A mampu mengerjakan PBI-001 sampai PBI-006 dalam durasi satu sprint dengan total weight 28. Sedangkan anggota B mampu mengerjakan PBI-001 sampai PBI-008 dengan total weight 32. Maka squad capacity adalah rata-ratanya yakni 30.
4. Tentukan buffer for rework. Buffer for rework adalah buffer untuk pekerjaan terdahulu yang harus disesuaikan kembali (rework) di sprint yang sedang berjalan karena terkena impact dari backlog yang sedang dikerjakan. Untuk menghitung buffer for rework, ambil 10% dari total squad capacity.
5. Tentukan buffer for changes. Buffer for changes adalah buffer untuk perubahan yang mungkin terjadi kepada backlog yang saat itu sedang dikerjakan. Untuk menghitung buffer for changes, ambil 10% dari total squad capacity.
6. Hitung velocity. Formula untuk menghitung total velocity adalah:

Velocity = squad capacity — (buffer for rework + buffer for changes)

Contoh perhitungan sprint velocity:

Contoh menghitung sprint velocity

Dengan mengetahui sprint velocity, dapat dihitung jumlah sprint yang diperlukan untuk mengerjakan seluruh backlog.

Jumlah sprint = Total weight / Sprint Velocity

Penutup

Pemahaman mengenai Product Backlog Item merupakan sebuah keharusan bagi seorang Product Owner. Mulai dari proses penentuan product goal, hingga membuat product backlog untuk mencapai product goal. Penentuan product backlog yang tepat akan memaksimalkan business value bagi para stakeholder, sedangkan penentuan product backlog yang tidak tepat dapat menyebabkan masalah tidak terselesaikan.

Artikel ini hanya membahas dasar yang perlu diketahui berdasarkan konteks yang kami alami. Untuk konteks atau situasi yang berbeda, detail pendekatan yang digunakan bisa jadi berbeda. Karena artikel ini masih bersifat dasar, masih banyak hal penting terkait backlog management yang perlu dibahas lebih lanjut. Seperti struktur backlog dalam bentuk feature, epic, dan backlog, metode breakdown task, variasi metode estimasi, penggunaan checkpoint, dan lain-lain. Semoga artikel ini bermanfaat. Terima Kasih.

Editor: AF