Materi
Scrum Guide 2020 menempatkan pengurutan Product Backlog pada Product Owner, dan keputusannya terlihat pada isi serta urutan backlog. Glosarium Agile Alliance merinci kegiatan penyempurnaan backlog: membuang cerita yang tidak lagi relevan, membuat cerita baru untuk kebutuhan yang baru ditemukan, menilai ulang prioritas, memberi estimasi pada cerita yang belum punya, mengoreksi estimasi, dan memecah cerita berprioritas tinggi yang terlalu besar untuk iterasi berikutnya.
GOV.UK Service Manual, bagian Deciding on priorities, menyatakan keputusan prioritas diambil berkala — misalnya mingguan untuk sprint backlog dan triwulanan untuk roadmap — berdasarkan analisis kinerja, riset pengguna, dan masukan pemangku kepentingan, dengan metode yang jelas dan melibatkan tim. Salah satu metode yang disebutnya adalah MoSCoW, yang memilah item backlog dan roadmap menjadi empat kelompok:
| Kelompok | Definisi GOV.UK (ditulis ulang) |
|---|---|
| Must have | Esensial: produk tidak bisa berfungsi tanpanya |
| Should have | Sangat memperbaiki produk, tetapi tidak krusial agar produk berfungsi |
| Could have | Memperbaiki layanan, tetapi tidak berdampak terlalu buruk bila ditinggalkan pada tahap ini |
| Won't have | Prioritas rendah yang disepakati tim untuk tidak dikerjakan |
Panduan yang sama mengingatkan bahwa backlog tidak hanya berisi fitur baru: tiket dukungan dan pekerjaan melunasi utang teknis ikut diprioritaskan. Di lembar kerja, total poin per kelompok dihitung dengan SUMIF atas kolom kelompok, sehingga tim bisa melihat berapa poin yang esensial dibanding seluruh backlog.
Contoh di aplikasi antrean klinik: menyimpan data pendaftaran pasien adalah must have, karena tanpanya aplikasi tidak berfungsi; pengingat jadwal lewat pesan adalah should have bila sangat memperbaiki layanan tetapi aplikasi tetap berjalan tanpanya; tema warna pilihan adalah could have; dan versi untuk jam tangan pintar yang disepakati tidak dikerjakan adalah won't have.
