Template product backlog: prioritas, bukti, dan langkah berikutnya
Unduh template product backlog CSV gratis dengan contoh masalah, dampak, prioritas, ketergantungan, dan acceptance criteria. Plus cara mengurutkan dan merapikan backlog.
Product backlog adalah daftar kandidat pekerjaan untuk memperbaiki produk, diurutkan dari yang paling bernilai. Semua ide tidak harus langsung masuk sprint. Template ini memisahkan masalah pengguna, hasil yang diharapkan, dan informasi yang masih kurang, agar tim dapat memutuskan apa yang siap dikerjakan.
Unduh template product backlog CSV
File CSV dapat dibuka di Google Sheets, Excel, atau spreadsheet lain tanpa akun. Isinya adalah contoh fiktif.
Apa itu product backlog?
Dalam Scrum, product backlog adalah satu-satunya sumber pekerjaan untuk Scrum Team. Product Owner bertanggung jawab atas isi dan urutannya. Item di bagian atas backlog harus cukup jelas untuk dipilih di sprint planning, sementara item di bagian bawah boleh masih berupa ide kasar.
Backlog bukan daftar janji. Item boleh diubah, digabung, atau dihapus ketika tim belajar hal baru. Penjelasan peran dan artifact Scrum lainnya ada di apa itu Scrum.
Kolom dalam template
| Kolom | Isi |
|---|---|
| Masalah | Masalah pengguna atau bisnis yang ingin diselesaikan |
| Hasil yang diharapkan | Perubahan yang terjadi jika masalah terselesaikan |
| Prioritas | High, Medium, atau Low |
| Alasan | Mengapa prioritas tersebut dipilih |
| Bukti yang perlu dikumpulkan | Data atau pengamatan untuk memastikan masalahnya nyata |
| Pemilik klarifikasi | Orang yang mencari informasi yang masih kurang |
| Ketergantungan | Keputusan atau pekerjaan lain yang perlu tersedia |
| Kriteria penerimaan | Kondisi yang bisa diuji untuk menyatakan selesai |
Mulai dari masalah pengguna
Contoh: penerima undangan tidak memahami mengapa tautan sudah tidak berlaku. Hasil yang diinginkan adalah pesan yang menjelaskan tindakan berikutnya. Solusi awal mungkin halaman status khusus, tetapi tim perlu memeriksa perilaku saat ini sebelum menentukan perubahan. Kolom bukti dapat berisi catatan pengujian yang sudah disamarkan, bukan informasi pribadi pelanggan.
Menulis masalah, bukan solusi, memberi ruang bagi tim untuk menemukan cara terbaik. “Tambahkan tombol kirim ulang undangan” adalah satu solusi; “penerima tidak tahu cara mendapat undangan baru” adalah masalah yang bisa diselesaikan dengan beberapa cara.
Cara mengurutkan kandidat pekerjaan
Tinjau dampak pada pengguna, urgensi, dan ketergantungan. Gunakan prioritas sederhana seperti High, Medium, atau Low, lalu tambahkan alasan singkat. Hindari memberi semua item prioritas tinggi; jika semuanya mendesak, tim tetap tidak tahu apa yang harus dikerjakan terlebih dahulu.
Untuk keputusan yang lebih sulit, beberapa teknik bisa membantu:
- Nilai dibanding usaha: kerjakan dulu item dengan dampak besar dan usaha kecil.
- MoSCoW: kelompokkan item menjadi Must have, Should have, Could have, dan Won’t have untuk periode ini.
- Risiko lebih dulu: kerjakan item yang paling tidak pasti lebih awal agar masalah ketahuan cepat.
Teknik ini membantu diskusi, tetapi keputusan akhir tetap di tangan pemilik prioritas.
Langkah mengisi template
- Tuliskan satu masalah atau hasil dalam setiap baris.
- Tambahkan contoh perilaku yang perlu berubah.
- Catat keputusan atau penelitian yang masih dibutuhkan.
- Tentukan pemilik klarifikasi, bukan langsung menjanjikan tanggal pengiriman.
- Pindahkan ke kandidat sprint setelah kriteria penerimaannya dapat diuji.
Contoh kriteria penerimaan
Untuk pesan tautan kedaluwarsa, penerima harus melihat bahwa undangan tidak dapat dipakai, memperoleh instruksi meminta undangan baru, dan tetap dapat menuju halaman login. Ketiga kondisi ini lebih mudah diuji daripada kalimat “perbaiki pengalaman undangan”. Jika perubahan melibatkan pengiriman email, pisahkan pekerjaan integrasi dan pengujian agar ketergantungan terlihat.
Format lengkap untuk menulis item yang jelas, termasuk user story, ada di cara menulis task yang jelas.
Contoh untuk tim non-teknis
Tim operasional toko online bisa memakai template yang sama:
- Masalah: pelanggan sering menanyakan status pengiriman lewat chat.
- Hasil yang diharapkan: pelanggan bisa melihat status pengiriman sendiri.
- Prioritas: High, karena menghabiskan sekitar dua jam waktu admin per hari (berdasarkan catatan chat minggu lalu).
- Bukti yang perlu dikumpulkan: jumlah pertanyaan status per minggu.
- Kriteria penerimaan: email konfirmasi berisi tautan pelacakan, dan halaman pesanan menampilkan nomor resi.
Rapikan backlog secara rutin
Backlog yang tidak dirawat cepat menjadi tempat ide terlupakan. Sediakan waktu singkat setiap minggu, sering disebut backlog refinement, untuk:
- Menghapus duplikasi dan ide yang tidak relevan lagi.
- Memperbarui prioritas berdasarkan informasi baru.
- Memecah item besar di bagian atas backlog.
- Menambahkan acceptance criteria pada item yang akan dipilih di sprint berikutnya.
Agenda refinement ada di panduan Scrum ceremonies.
Tanda backlog yang sehat
- Item teratas cukup jelas untuk satu atau dua sprint ke depan.
- Setiap item punya alasan prioritas.
- Tidak ada item yang diam di backlog lebih dari beberapa bulan tanpa ditinjau.
- Tim bisa menjelaskan mengapa item nomor satu lebih penting dari nomor dua.
- Ide yang ditolak dicatat alasannya, sehingga tidak terus diusulkan ulang.
- Stakeholder tahu di mana dan bagaimana mengusulkan item baru.
Pertanyaan yang sering diajukan
Apa beda product backlog dan sprint backlog?
Product backlog berisi semua kandidat pekerjaan untuk produk, diurutkan berdasarkan nilai. Sprint backlog hanya berisi item yang dipilih untuk sprint saat ini beserta rencana pengerjaannya. Item berpindah dari product backlog ke sprint backlog saat sprint planning.
Berapa banyak item yang ideal di backlog?
Tidak ada angka pasti. Yang penting, item untuk satu sampai dua sprint ke depan sudah jelas. Jika backlog berisi ratusan item yang tidak pernah disentuh, kemungkinan besar banyak di antaranya tidak akan pernah dikerjakan dan sebaiknya diarsipkan.
Siapa yang boleh menambah item ke backlog?
Siapa pun boleh mengusulkan item: tim, stakeholder, atau tim support yang mendengar keluhan pelanggan. Namun, urutan backlog diputuskan oleh satu orang, yaitu Product Owner atau pemilik prioritas, agar tidak ada prioritas yang saling bertabrakan.
Apakah backlog harus ditulis sebagai user story?
Tidak wajib. User story membantu mengingat siapa yang dilayani, tetapi bug, pekerjaan teknis, dan task administratif sering lebih jelas ditulis langsung sebagai masalah dan hasil.
Seberapa sering backlog perlu dirapikan?
Untuk sprint satu atau dua minggu, refinement 30–60 menit setiap minggu biasanya cukup. Tim Kanban bisa merapikan antrean Ready setiap kali review mingguan.
Melanjutkan di Moovit
Untuk melanjutkan di Moovit, buat task dengan status Backlog, lalu pilih label dan prioritas yang sesuai. Item yang sudah jelas dipindah ke Ready. Template ini bukan format impor otomatis, jadi task perlu dibuat secara manual.
Lanjutkan ke template sprint planning ketika task siap dipilih.