Backlog Refinement: Cara Memperhalusi Product Backlog Anda

Backlog refinement (dahulunya dipanggil "backlog grooming") ialah amalan berulang yang memastikan product backlog anda tidak bertukar menjadi kubur bagi kerja yang kabur, lapuk, dan tidak dianggar. Apabila dilakukan dengan baik, pasukan anda akan memasuki setiap mesyuarat sprint planning dengan sudah mengetahui apa maksud item teratas, seberapa besar ia, dan mengapa ia penting.

Apakah backlog refinement?

Backlog refinement ialah proses berterusan untuk menyemak, menjelaskan, menganggar, dan menyusun semula item dalam product backlog supaya ia sedia untuk Sprint yang akan datang. Matlamatnya adalah untuk memastikan backlog kekal terkini, diutamakan, dan difahami dengan baik oleh semua orang yang akan bekerja dengannya.

Fakta utama: backlog refinement

• Pasukan yang mengadakan sesi backlog refinement yang tetap melaporkan 20-30% lebih sedikit permintaan penjelasan semasa sprint planning, menurut Laporan State of Scrum Scrum Alliance (2023).
• Panduan Scrum mengesyorkan memperuntukkan tidak lebih daripada 10% kapasiti Sprint pasukan pembangunan untuk backlog refinement (Scrum.org, 2020).
• Dalam tinjauan 2022 oleh Digital.ai, 68% pasukan agile menyatakan item backlog yang tidak dianggar atau tidak ditakrifkan dengan baik adalah antara tiga punca utama kegagalan Sprint.

Refinement bukan satu ceremony Scrum rasmi dalam Panduan Scrum; ia disenaraikan sebagai aktiviti berterusan. Tetapi kebanyakan pasukan berprestasi tinggi menganggapnya sebagai mesyuarat berulang kerana disiplin untuk melakukannya secara sengaja, mengikut jadual, adalah yang membuatnya benar-benar berkesan.

Siapa yang hadir dan seberapa kerap

Peserta teras adalah product owner dan pasukan pembangunan. Product owner membawa konteks perniagaan, keutamaan, dan keperluan baharu. Pembangun membawa perspektif teknikal; merekalah yang akan menyedari bahawa ciri yang "mudah" sebenarnya melibatkan tiga perkhidmatan, atau bahawa dua kisah sebenarnya perkara yang sama yang dinyatakan secara berbeza.

Pihak berkepentingan, pereka UX, dan pakar bidang boleh turut serta apabila item tertentu memerlukan input mereka, tetapi mengekalkan kumpulan teras yang kecil memastikan sesi kekal fokus.

Kadar: Kebanyakan pasukan mengadakan satu sesi refinement setiap Sprint, biasanya pada pertengahan Sprint, supaya item teratas Sprint seterusnya sedia sebelum sprint planning tiba. Sprint dua minggu sering menyokong sesi refinement selama 60-90 minit. Sesetengah pasukan lebih suka dua sesi yang lebih pendek selama 45 minit yang tersebar dalam Sprint; ini bergantung pada kadar pertukaran backlog dan saiz pasukan.

Panduan 10% kapasiti daripada Panduan Scrum adalah siling yang berguna. Untuk Sprint dua minggu dengan pasukan lima orang, itu kira-kira empat jam-orang secara keseluruhan, yang sepadan dengan satu sesi 45-60 minit.

Apa yang berlaku dalam backlog refinement

Sesi refinement merangkumi lima aktiviti utama:

Memecah item besar. Epic dan kisah pengguna yang besar dipecahkan kepada kepingan yang lebih kecil dan bersesuaian dengan Sprint. Kisah yang mengambil masa tiga minggu untuk dibina perlu dipecah kepada tiga atau empat kisah bebas yang masing-masing boleh diselesaikan dalam satu Sprint.

Menambah kriteria penerimaan dan butiran. Item yang kabur seperti "tingkatkan aliran pembayaran" diubah kepada keperluan yang spesifik dan boleh diuji. Apa maksud "ditingkatkan"? Masa muat yang lebih pantas? Lebih sedikit langkah? Untuk peranti yang mana? Pasukan bersetuju dengan kriteria sebelum membuat komitmen.

Menganggar usaha. Item disaizkan menggunakan story point atau unit anggaran lain. Ramai pasukan menggunakan planning poker untuk mencapai anggaran konsensus tanpa penjangkaran. Anggaran paling berharga untuk item dua atau tiga Sprint teratas dalam backlog; item yang lebih jauh akan berubah terlalu banyak untuk anggaran yang tepat.

Menyusun semula item. Keutamaan berubah. Ciri yang berada di kedudukan 15 minggu lalu mungkin melompat ke kedudukan 3 selepas panggilan pelanggan. Product owner menyesuaikan susunan berdasarkan nilai, risiko, kebergantungan, dan maklum balas.

Membuang item lapuk. Item yang tidak lagi masuk akal, kerana pasaran berubah, ciri telah dihantar dalam bentuk yang berbeza, atau ia telah tergantung tanpa disentuh selama enam bulan, dibuang atau diarkibkan. Backlog yang terlalu besar adalah masalah kepercayaan: jika pasukan melihat ratusan item dan tahu kebanyakannya tidak akan pernah dibina, mereka berhenti mengambil senarai itu dengan serius.

Backlog refinement berbanding sprint planning

Kedua-dua ceremony ini sering mengelirukan kerana kedua-duanya melibatkan backlog. Tetapi ia memenuhi tujuan yang berbeza dan berlaku pada masa yang berbeza.

Anggap refinement sebagai persediaan dan sprint planning sebagai komitmen. Melangkau refinement bermakna sprint planning menjadi sesi penyelidikan, yang lambat dan tidak selesa untuk semua orang.

Manfaat refinement yang tetap

Sprint planning yang lebih pantas. Apabila item sudah dianggar dan ditakrifkan dengan jelas, sprint planning mengambil masa 30-60 minit dan bukannya separuh hari. Pasukan tidak menemui kisah buat kali pertama.

Anggaran yang lebih baik. Kualiti anggaran bertambah baik apabila pasukan berbincang tentang item sebelum tekanan Sprint bermula. Ada ruang untuk bertanya, menolak skop, dan mengkalibrasi semula.

Lebih sedikit gangguan Sprint. Keperluan yang kabur menjana permintaan penjelasan di tengah-tengah Sprint. Kisah yang telah diperhalusi terlebih dahulu dengan kriteria penerimaan dan kes tepi mengurangkan perbualan "tunggu, apa maksud ini sebenarnya?" yang memecah aliran.

Pemahaman produk yang dikongsi. Pembangun yang menghadiri refinement membina model mental yang lebih jelas tentang hala tuju produk. Ini menjadikan mereka lebih baik dalam mengesan kebergantungan teknikal, mengemukakan risiko lebih awal, dan mencadangkan pendekatan yang lebih mudah sebelum kerja bermula.

Kebersihan backlog yang lebih sihat. Pemangkasan yang tetap memastikan backlog terurus. Pasukan yang menyemak backlog setiap Sprint secara semula jadi akan memangkasnya, yang menjadikan pengutamaan lebih mudah dan perancangan lebih dipercayai.

Definition of Ready (DoR)

Definition of Ready ialah senarai semak yang dikongsi yang mesti dilalui oleh item backlog sebelum pasukan menganggapnya layak untuk memasuki Sprint. Ia adalah setara backlog bagi Definition of Done; keduanya mewujudkan piawaian yang dikongsi, hanya pada hujung kitaran kerja yang berbeza.

Definition of Ready yang tipikal merangkumi:

• Tajuk dan penerangan yang jelas: Kisah menerangkan apa yang perlu dibina dan untuk siapa.
• Kriteria penerimaan: Pasukan tahu apa maksud "selesai" untuk item ini.
• Saiz yang dianggar: Item telah disaizkan menggunakan story point atau setarafnya.
• Kebergantungan dikenal pasti: Sebarang halangan, kebergantungan luaran, atau item pendahulu didokumentasikan.
• Sesuai dalam Sprint: Item cukup kecil untuk diselesaikan dalam satu Sprint. Jika tidak, ia perlu dipecah.
• Artifak reka bentuk atau UX dilampirkan (jika berkenaan): Mockup, spesifikasi, atau kontrak API yang berkaitan dipautkan.

DoR bukan pintu birokrasi; ia adalah persetujuan bersama yang melindungi pasukan daripada menarik kerja yang kabur ke dalam Sprint dan mendapati pada pertengahan minggu bahawa tiada siapa yang tahu apa maksudnya. Jika item tidak memenuhi DoR semasa refinement, product owner mengambilnya kembali untuk kerja lanjut sebelum sesi seterusnya.

Cara menjalankan sesi backlog refinement

Langkah 1: Sediakan backlog sebelum mesyuarat

Product owner menyemak 20-30 item teratas sebelum sesi bermula. Mereka menambah sebarang konteks yang hilang, menandakan item yang sedia untuk anggaran, dan mengambil mana-mana item baharu yang telah ditambah sejak sesi terakhir. Memasuki refinement tanpa persediaan membuang masa semua orang.

Langkah 2: Teliti item keutamaan tertinggi

Mulakan dari bahagian atas backlog dan turun ke bawah. Untuk setiap item, product owner menerangkan konteks dan matlamatnya. Pastikan penerangan ringkas; refinement bukan demo atau semakan reka bentuk, ia adalah pemeriksaan kejelasan.

Langkah 3: Jelaskan dan tambah kriteria penerimaan

Pasukan bertanya soalan. Apakah kes tepinya? Apa yang berlaku jika pengguna melakukan X? Adakah ada kekangan peranti atau pelayar? Product owner atau pakar bidang menjawab. Sebarang kriteria penerimaan yang dipersetujui ditambah ke kisah sebelum berpindah.

Langkah 4: Anggar menggunakan story point

Selepas kisah jelas, pasukan membuat anggaran. Gunakan planning poker atau teknik konsensus lain untuk mengelakkan penjangkaran. Jika anggaran berbeza dengan ketara, orang dengan anggaran tertinggi dan terendah menjelaskan alasan mereka; ini mendedahkan kerumitan tersembunyi atau andaian yang tidak selaras.

Item yang terlalu besar untuk dianggar ditanda untuk dipecah dan kembali ke langkah 2 sebagai kisah yang lebih kecil.

Langkah 5: Sahkan kesediaan dan susun semula

Selepas berbincang dan menganggar, sahkan sama ada item memenuhi Definition of Ready anda. Jika ya, ia layak untuk Sprint yang akan datang. Jika tidak, catat apa yang hilang dan berikan pemilikan jurang itu. Akhirnya, sahkan susunan keutamaan item teratas sebelum menutup sesi.

Retrospektif ringkas di penghujung, "apa yang menjadikan sesi refinement ini berkesan atau tidak berkesan?" meningkatkan kualiti dari masa ke masa.

Kesilapan biasa

Menganggap refinement sebagai sprint planning. Sesetengah pasukan cuba berkomit kepada item Sprint semasa refinement. Ini mencampurkan dua keputusan yang berbeza: apa yang sedia untuk dikerjakan, dan apa yang kita komit untuk Sprint ini. Pisahkan keduanya.

Memperhalusi terlalu jauh ke hadapan. Memperuntukkan masa yang banyak untuk menganggar dan merinci item yang 10 Sprint ke depan biasanya adalah usaha yang sia-sia. Keperluan berubah. Fokus pada 2-3 Sprint seterusnya dengan terperinci; simpan item yang lebih jauh sebagai idea kasar atau epic.

Melangkauinya apabila backlog terasa "baik." Backlog sebenarnya tidak pernah terasa baik sehingga ia tiba-tiba menjadi krisis semasa sprint planning. Refinement adalah disiplin yang mencegah krisis, bukan tindak balas terhadapnya.

Hanya product owner yang hadir. Apabila pembangun tidak hadir dalam refinement, anggaran dilakukan kemudian di bawah tekanan masa, kerumitan teknikal terlepas, dan kisah tiba di sprint planning dengan andaian yang dibina masuk yang tidak pernah dipersetujui oleh pasukan. Semua orang yang berkaitan perlu hadir.

Membiarkan sesi berjalan lama. Sebaik sahaja refinement melepasi 90 minit, tumpuan menurun dengan ketara. Jika anda membuang banyak masa dan masih ada item yang belum diperhalusi, lebih baik menjadualkan sesi susulan daripada meneruskan dengan ruangan yang keletihan. Sesi yang lebih pendek dan lebih kerap sering lebih berkesan daripada satu sesi bulanan yang panjang.

Tidak pernah memangkas item lama. Item backlog yang telah berada di kedudukan 40-150 selama lebih tiga bulan perlu dipersoalkan. Jika pasukan tidak dapat menyatakan mengapa item itu masih relevan, arkibkannya. Anda sentiasa boleh memulihkannya.

Soalan lazim

Berapa lama sesi backlog refinement sepatutnya? Panduan 10% kapasiti daripada Panduan Scrum bermakna kira-kira 60-90 minit untuk Sprint dua minggu. Sesetengah pasukan menjalankan dua sesi 45 minit setiap Sprint berbanding satu sesi yang lebih panjang. Kekalkan di bawah 90 minit dalam satu sesi; kualiti menurun selepas itu.

Siapa yang memiliki mesyuarat backlog refinement? Product owner bertanggungjawab memastikan backlog berada dalam keadaan baik, jadi mereka biasanya memudahkan atau bersama-sama memudahkan refinement. Scrum master membantu dengan kualiti proses dan fasilitasi. Tetapi refinement berfungsi paling baik apabila ia adalah kerjasama, bukan monolog product owner.

Apakah perbezaan antara "ready" dan "refined"? Item yang telah diperhalusi telah dibincangkan dan mempunyai kriteria penerimaan yang ditambah. Item yang "sedia" telah lulus Definition of Ready, iaitu ia telah dianggar, cukup kecil untuk Sprint, dan tiada kebergantungan yang belum diselesaikan. Setiap item yang sedia adalah telah diperhalusi, tetapi tidak setiap item yang telah diperhalusi semestinya sedia.

Perlukah pereka hadir dalam backlog refinement? Ia bergantung pada jenis kerja. Untuk kisah dengan pertimbangan UX atau reka bentuk visual yang ketara, kehadiran pereka mencegah salah faham skop dan mengelakkan kerja semula reka bentuk di pertengahan Sprint. Untuk kerja backend atau infrastruktur, masa mereka lebih baik digunakan di tempat lain.

Seberapa kerap backlog patut dipangkas? Semakan ringan setiap Sprint (membuang item yang jelas lapuk) ditambah audit yang lebih mendalam setiap suku tahun berfungsi dengan baik untuk kebanyakan pasukan. Audit suku tahunan mengesan item yang terlepas dari relevan tanpa ada yang menyedari.

---

Backlog refinement adalah salah satu amalan yang mudah dilangkau apabila keadaan sibuk, namun tepat itulah masanya ia menyebabkan paling banyak kerosakan apabila dilangkau. Backlog yang telah diperhalusi dengan baik itulah yang memisahkan pasukan yang berlari Sprint dengan yakin daripada pasukan yang sentiasa memerangi kekeliruan skop. Bina tabiat itu lebih awal, jaga masa itu, dan kesan berganda akan kelihatan dengan cepat dalam kualiti sprint planning anda.

Bacaan Berkaitan

• Product Backlog - struktur, pemilikan, dan teknik pengutamaan
• Sprint Planning - cara mengubah backlog yang telah diperhalusi menjadi komitmen Sprint
• Kisah Pengguna - menulis kisah yang cukup jelas untuk diperhalusi
• Story Point - memahami unit anggaran usaha
• Planning Poker - teknik anggaran konsensus untuk sesi refinement
• Definition of Done - pasangan penyiapan bagi Definition of Ready
• Daily Standup - mengekalkan penjajaran pelaksanaan Sprint selepas refinement