5 Strategi Efektif Untuk Product Backlog Refinement

Mata kuliah : Agile and Scrum Methods

Dosen Pengampu : Sabo Hermawan, S.Kom., M.Si.

⁠Kelompok :

1.Nursiah 1710623039

2. Anggi Agnesia Siagian 1710623013

3. Azka Fadzilla 1710623088

4. Ratu Ramallah Tuffahati 1710623023

5. Sekar Puspita Anjani 1710623081

6. Zahra Putri Erlysta 1710623055

Dalam Scrum, refinement sebenarnya berlangsung terus-menerus. Mulai di Sprint Review, setelah Daily Scrum, saat Sprint Planning, hingga selama pengembangan. Setiap diskusi tentang pekerjaan yang akan datang adalah bagian dari upaya membangun pemahaman bersama agar Product Backlog selalu relevan dan jelas.

Beberapa fokus utama dalam refinement meliputi:

• Memperjelas hasil atau deliverables
• Memecah pekerjaan menjadi bagian yang lebih kecil namun tetap bernilai
• Mengurutkan item berdasarkan prioritas dan tujuan tim/organisasi
• Menambahkan pekerjaan baru dan menghapus yang sudah tidak relevan
• Mengurangi dependency antar pekerjaan
• Memperkirakan ukuran dan nilai setiap item
• Memahami asumsi-asumsi yang ada dalam pekerjaan

Intinya, Product Backlog Refinement adalah aktivitas yang berfokus pada pekerjaan masa depan, yakni item-item yang ada di dalam Product Backlog. Barry Overeem menyebut Product Backlog items sebagai “pengingat untuk percakapan yang harus terjadi di masa depan”. Artinya, setiap item bukanlah instruksi yang sudah final, tetapi titik awal untuk diskusi lebih lanjut. Dengan kata lain, refinement adalah proses berkelanjutan untuk memastikan percakapan-percakapan penting itu terus terjadi. Karena itu, refinement bukan sekadar ritual teknis, tetapi bagian esensial dari product management yang membantu tim memastikan bahwa mereka selalu mengerjakan hal yang paling bernilai.

Mengapa Product Backlog Refinement Diperlukan?

Refinement diperlukan agar Scrum Team memiliki pemahaman yang sama tentang setiap item di Product Backlog. Melalui diskusi dan pemecahan item menjadi bagian yang lebih kecil, tim bisa yakin bahwa pekerjaan tersebut dapat diselesaikan dalam satu Sprint. Ini membuat Backlog lebih transparan dan mengurangi risiko item tidak selesai, yang berarti kehilangan peluang menciptakan nilai bagi organisasi.

Scrum Team juga hanya memfokuskan refinement pada item teratas karena wawasan baru yang muncul selama pengerjaan bisa mengubah prioritas atau membuat item lain menjadi tidak relevan. Untuk menjaga efisiensi, Developers biasanya menghabiskan sekitar 10% waktu mereka untuk aktivitas ini.

5 Strategi Efektif untuk Product Backlog Refinement

Menurut Scrum Zombie Guide, sebanyak 43% Scrum Team tidak melakukan refinement untuk pekerjaan Sprint berikutnya. Padahal, refinement adalah aktivitas penting dalam Product Management untuk memastikan Product Backlog tetap jelas, relevan, dan siap dikerjakan. Berikut lima strategi yang dapat membantu Scrum Team melakukan refinement dengan lebih efektif dan terstruktur:

1. Gaining Insights

Agar Scrum Team memiliki pemahaman yang sama tentang pekerjaan, mereka perlu menemukan insight bersama dengan para stakeholder. Dua alat yang membantu proses ini adalah Hypothesis Canvas dan UX Fishbowl.

• Hypothesis Canvas

Dalam pengembangan produk, hal yang tidak diketahui seringkali lebih banyak daripada yang diketahui. Pelanggan berubah, teknologi berkembang, dan organisasi sering kali masih terjebak pada prediksi dan rencana detail yang tidak realistis. Scrum Team yang sukses tidak langsung fokus pada fitur, tetapi mulai dari memahami masalah pelanggan dan membuat asumsi tentang solusi yang mungkin. Hypothesis Canvas, yang terinspirasi dari Lean UX Canvas milik Jeff Gothelf, membantu tim:

1. Melihat Product Backlog items bukan sebagai kebutuhan pasti, tetapi sebagai hipotesis tentang bagaimana menciptakan nilai
2. Berpikir kreatif mengenai masalah dan solusi
3. Menetapkan kriteria sukses yang jelas: apa hasil yang diharapkan pengguna dan dampaknya pada Product Goal.

Dalam sesi refinement, Scrum Team dan stakeholder bersama-sama mengembangkan dan menguji hipotesis ini.

• UX Fishbowl

UX Fishbowl adalah metode diskusi yang membantu Scrum Team memahami bagaimana sebuah fitur akan digunakan dari perspektif stakeholder. Strukturnya terdiri dari dua kelompok (stakeholder & Scrum Team) dan dua langkah berulang:

1. Stakeholder berdiskusi seolah fitur sudah ada: bagaimana mereka menggunakannya, kapan, mengapa, langkah-langkahnya, apa yang bermanfaat, dan apa yang menghambat.
2. Scrum Team mendengarkan dan mencatat insight penting, lalu merumuskan pertanyaan lanjutan untuk putaran berikutnya.

Melalui UX Fishbowl, ide-ide besar dapat dipecah menjadi Product Backlog items yang lebih kecil namun tetap bernilai bagi stakeholder.

2. Ordering the Product Backlog

Mengurutkan Product Backlog bukan tugas Product Owner saja. Ketika Scrum Team bekerja sama dengan stakeholder, mereka mendapatkan perspektif baru tentang apa yang paling bernilai bagi produk. Dua metode yang membantu proses ini adalah Buy a Feature dan 20/20 Vision.

• Buy a Feature

Metode ini melibatkan stakeholder dalam memilih item yang paling bernilai. Prosesnya dapat dilakukan sebagai berikut:

1. Setiap Product Backlog item diberi harga.
2. Stakeholder menerima uang dengan jumlah sama.
3. Mereka “membeli” item yang menurut mereka paling penting (item hanya bisa dibeli sekali).
4. Uang dapat digabung untuk membeli item yang lebih mahal.
5. Hasil pembelian menunjukkan prioritas kolektif.

Harga beberapa item sengaja dibuat tinggi agar stakeholder harus berdiskusi dan berkolaborasi menentukan pilihan terbaik.

• 20/20 Vision

20/20 Vision adalah metode sederhana untuk menyusun prioritas berdasarkan persepsi stakeholder. Prosesnya dapat dilakukan sebagai berikut:

1. Setiap item ditulis pada kartu terpisah, lalu semua kartu diacak.
2. Kartu pertama dibuka sebagai referensi.
3. Kartu berikutnya dibuka satu per satu dan stakeholder menentukan apakah item lebih penting atau kurang penting dibanding referensi.
4. Proses diulang hingga seluruh kartu tersusun rapi berdasarkan prioritas.

Hasilnya adalah urutan Product Backlog yang merefleksikan pandangan stakeholder secara jelas dan terstruktur.

3. Estimating Product Backlog Items

Estimasi Product Backlog bukan untuk mengetahui usaha pasti, melainkan untuk membangun pemahaman bersama (shared understanding) tentang pekerjaan. Scrum Team menilai ukuran item secara relatif, dibandingkan dengan item lain, karena lebih mudah dibanding mengukur secara absolut. Dua teknik populer adalah Magic Estimation dan Planning Poker.

• Magic Estimation

Metode ini memungkinkan Scrum Team memperkirakan banyak item dengan cepat. Langkah-langkah yang dapat dilakukan antara lain:

1. Gunakan deret Fibonacci (1, 2, 3, 5, 8, 13, 21, ?) sebagai pilihan ukuran
2. Tentukan satu item sebagai referensi ukuran.
3. Sebarkan item lain ke Developers.
4. Developers memberi ukuran secara diam-diam, dibandingkan dengan item referensi. Item yang belum dipahami diberi tanda “?”.
5. Setelah semua item diberi ukuran, Developers meninjau hasil satu sama lain dan mengubah ukuran jika tidak setuju.
6. Jika tidak ada kesepakatan, pilih ukuran di antara dua nilai terdekat atau klarifikasi dengan Product Owner jika masih tanda “?”.

Hasilnya adalah Product Backlog yang telah diperkirakan relatif terhadap item referensi, sehingga lebih konsisten.

• Planning Poker

Metode ini membantu tim mencapai kesepakatan melalui diskusi, mirip permainan poker. Langkah-langkah yang dapat dilakukan antara lain:

1. Product Owner menjelaskan item yang akan diestimasi.
2. Setiap Developer memilih ukuran secara individu (tetap tersembunyi).
3. Semua kartu dibuka bersamaan.
4. Jika terdapat perbedaan besar, Developers berdiskusi lalu mengulangi estimasi.
5. Siklus ini diulang hingga tercapai kesepakatan.

Ukuran dapat menggunakan angka Fibonacci, jari tangan, T-shirt sizes, atau metode kreatif lain.

4. Breaking down Product Backlog Items

Scrum Team memecah Product Backlog items agar setiap bagian langsung memberikan nilai dan dapat digunakan. Pemecahan dilakukan secara vertikal, bukan hanya teknis, sehingga tiap item tetap bermanfaat bagi pengguna. Dua cara pemecahan yang umum antara lain:

1. Berdasarkan Workflow Steps

Jika sebuah item mencakup alur kerja, item tersebut dapat dipecah menjadi langkah-langkah kecil yang tetap memberi nilai utuh. Contoh Product Backlog item: “Customer dapat menyelesaikan pembayaran.”

Dapat dipecah menjadi:

• Sebagai pelanggan, saya bisa login ke akun saya.
• Sebagai pelanggan, saya bisa melakukan pembayaran.
• Sebagai pelanggan, saya menerima email konfirmasi pesanan.

Setiap item berdiri sendiri dan bernilai bagi pengguna.

2. Berdasarkan Happy & Unhappy Paths

Fitur biasanya memiliki alur ideal (happy path) dan alur saat terjadi masalah (unhappy path). Keduanya dapat dipecah menjadi item terpisah. Contoh item: “Customer dapat login.”

Dapat dipecah menjadi:

• Happy path: Sebagai pelanggan, saya dapat login menggunakan akun saya.
• Unhappy path: Sebagai pelanggan, saya dapat mereset password jika login gagal.

Pemecahan ini membantu Scrum Team mengerjakan nilai utama terlebih dahulu sambil tetap menyiapkan fitur pendukung.

5. Eliminating dependencies

Meskipun Scrum Team bersifat cross-functional, lingkungan kerja yang kompleks bisa menimbulkan dependency yang tidak terduga. Dependency ini dapat menghambat pengurutan Product Backlog, menambah risiko keterlambatan, dan membuat Increment sulit diselesaikan dalam satu Sprint. Ada dua jenis dependency utama:

1. Internal Dependencies

Terjadi antar Product Backlog Items (PBIs), misalnya:

• Pekerjaan yang saling bergantung dalam alur kerja.
• Item yang harus dirilis bersamaan.
• Item yang memberikan nilai lebih besar jika dikerjakan secara urut atau bersama.

2. External Dependencies

PBIs bergantung pada faktor di luar tim, seperti:

• Proses bisnis (release, procurement).
• Sistem pihak ketiga.
• Perubahan teknis di area yang tidak dikuasai tim.
• Kebutuhan akan keahlian khusus dari pihak eksternal.

Cara Membuat Dependencies Terlihat

• Identifikasi semua dependencies dalam Backlog.
• Tandai dengan panah untuk memperjelas hubungan antar item atau pihak eksternal.
• Buat graf dengan item sebagai node dan panah sebagai edges untuk mem visualisasi pola ketergantungan

Cara Menghilangkan Dependencies

• Memecah PBIs agar tidak saling mengunci.
• Mengatur ulang prioritas Backlog.
• Mencari solusi teknis alternatif agar tidak bergantung pada pihak luar.
• Berkolaborasi lebih awal dengan tim lain.
• Mengakuisisi atau membangun keahlian yang dibutuhkan di dalam tim.

Product Backlog Refinement is Essential

Product Backlog Refinement adalah aktivitas penting dalam Scrum. Dengan memperoleh wawasan atas pekerjaan mendatang, mengurutkan item dalam Product Backlog, melakukan estimasi, memecah item yang kompleks, serta menghilangkan dependencies, Scrum Teams dan para stakeholder dapat membangun pemahaman bersama mengenai pekerjaan yang akan dikerjakan. Aktivitas ini krusial karena membantu mengurangi risiko kegagalan tim dalam menghasilkan Done Increment di setiap Sprint.

Product Backlog Refinement bukan hanya sesi teknis, tetapi proses kolaboratif yang memastikan setiap anggota tim memahami nilai, tujuan, dan konteks pekerjaan. Dengan melakukan refinement secara konsisten, Scrum Teams dapat bekerja lebih fokus, adaptif, dan berorientasi nilai. Pada akhirnya, refinement yang baik membantu tim menciptakan increment yang benar-benar bermanfaat dan mempertahankan laju pengembangan yang sehat dari sprint ke sprint.