Backlog Refinement (Backlog İyileştirme) Nasıl Yapılır?

Backlog refinement nedir?

Backlog refinement, Product Backlog'daki maddelerin ileride işlenmeye hazır hale gelmesi için ayrıntılandırılması, parçalanması ve sıralanmasıdır. Daha eski kullanımda "backlog grooming" olarak da anılır; Scrum çerçevesinde bu faaliyet için "refinement" terimi tercih edilir.

Önemli bir ayrım şudur: refinement, ekibin zamanını bloklayan tek bir toplantıdan ibaret değil, sürekli yürüyen bir çalışmadır. Product Owner ve Developers (geliştiriciler) birlikte, hangi maddenin ne kadar ayrıntıya ihtiyacı olduğuna karar verir. Yakın zamanda işlenecek maddeler daha net ve küçük, uzak vadeli maddeler daha kaba bırakılır. Bu, gelecekle ilgili aşırı ayrıntıya yatırım yapıp sonra değişen önceliklerle boşa çıkmayı önler.

Refinement neden gereklidir?

Belirsiz bir madde ekibe geldiğinde sprint planlamasında uzun tartışmalar çıkar, geliştiriciler eksik bilgiyi tamamlamak için iş ortasında Product Owner'a ulaşmaya çalışır ve iş tahmin edilenden büyük çıkar. Refinement bu sürprizleri planlamadan önce yakalar.

Sağladığı faydalar şunlardır: planlama oturumunun kısalması, ekibin işin içeriğini ortak anlaması, bağımlılıkların ve risklerin erken görülmesi, ve büyük maddelerin teslim edilebilir küçük parçalara bölünmesi. Ek olarak Product Owner için de yararı vardır: maddeler tartışılırken değer varsayımları sorgulanır, bazı maddeler gereksiz bulunup çıkarılır.

Adım adım refinement nasıl yürütülür?

Verimli bir refinement çalışması genellikle şu akışı izler:

• Hazırlık: Product Owner, üzerinde çalışılacak adayları sıraya koyar ve gerekli arka plan bilgisini (kullanıcı sorunu, iş hedefi, varsa tasarım) toplar.
• Maddeyi anlatmak: Madde ekibe kullanıcı açısından anlatılır; ekip sorular sorar.
• Parçalamak: Büyük madde, tek başına değer taşıyan daha küçük parçalara ayrılır.
• Kabul kriterlerini yazmak: Maddenin tamamlandığının nasıl anlaşılacağı somutlaştırılır.
• Tahmin etmek: Ekip, işin görece büyüklüğünü kendi yöntemiyle belirler.
• Sıralamak: Product Owner, değer ve bağımlılıklara göre maddeyi backlog'daki yerine yerleştirir.

Ya madde net değilse? Sorular not alınır, sorumlusu belirlenir ve madde bir sonraki çalışmada yeniden ele alınır. Her toplantıda her şeyi bitirmeye çalışmak yerine, öncelikli maddeleri doyurucu şekilde hazırlamak daha verimlidir.

Örnek bir akış: Product Owner "kullanıcı siparişini iptal edebilsin" maddesini getirir. Ekip önce hangi aşamaya kadar iptal mümkün olacağını sorar, ardından maddeyi iptal talebi, iade işlemi ve bilgilendirme e-postası gibi bağımsız teslim edilebilir parçalara böler. Her parça için kabul kriteri yazılır; iade kuralları netleşmediği için ilgili parça "sorular açık" olarak işaretlenir ve sorumlusu belirlenir. Böylece planlamaya yalnızca hazır parçalar girer.

İyi bir user story nasıl yazılır?

User story, bir ihtiyacı kullanıcı perspektifinden anlatan kısa bir ifadedir. Yaygın kalıp şudur: "Bir [kullanıcı] olarak, [amaç] istiyorum; böylece [fayda] elde edebileyim." Kalıbın amacı, ekibe ne yapılacağını değil neden yapılacağını hatırlatmaktır.

Örneğin: "Bir müşteri olarak siparişimin kargo durumunu görmek istiyorum; böylece teslimatı beklerken planımı yapabileyim." Bu ifade çözümü dayatmıyor, ihtiyacı anlatıyor; ekip uygulamayı en uygun biçimde seçebiliyor.

Story kalitesini değerlendirmek için sıkça kullanılan ölçüt kümesi INVEST'tir: bağımsız, müzakere edilebilir, değerli, tahmin edilebilir, küçük ve test edilebilir. Bir madde bu ölçütlerden birine uymuyorsa genellikle parçalanması ya da netleştirilmesi gerekir.

Kabul kriterleri ve Definition of Ready

Kabul kriterleri, bir maddenin beklenen davranışını örneklerle tanımlar. Yazarken "verilen durum, yapılan eylem, beklenen sonuç" düzeni işe yarar: giriş yapmış kullanıcı siparişi açtığında kargo durumunu görmelidir; sipariş henüz kargoya verilmediyse bu durum açıkça belirtilmelidir. Kriterler hem geliştirme hem test için ortak referans olur.

Definition of Ready ise bir maddenin sprinte alınmaya hazır sayılması için ekibin kendi belirlediği ölçütlerdir. Örneğin madde anlaşılır, kabul kriterleri yazılmış, bağımlılıkları belli ve ekibin bir sprintte bitirebileceği büyüklükte olmalıdır. Bu bir Scrum Guide gerekliliği değil, birçok ekibin kullandığı bir pratiktir; katı bir kapıya dönüştürüldüğünde işi yavaşlatabileceği unutulmamalıdır.

Tahminleme ve önceliklendirme

Tahminleme, kesin süre vermekten çok maddeler arasında göreli büyüklüğü karşılaştırmaktır. Story point, tişört bedenleri ya da benzer bir göreli ölçek kullanılabilir; önemli olan ekibin aynı ölçeği tutarlı biçimde kullanması ve tartışmanın sayıdan çok varsayımları ortaya çıkarmaya hizmet etmesidir.

Önceliklendirme ise Product Owner'ın sorumluluğundadır. Karar verirken iş değeri, kullanıcı etkisi, risk, bağımlılıklar ve öğrenme fırsatı birlikte tartılır. Değeri yüksek ama belirsizliği çok olan bir maddeyi öne çekip küçük bir deneyle riski azaltmak, büyük bir maddeyi doğrudan geliştirmekten daha güvenlidir.

Önceliklendirmede Product Owner değeri tek başına tahmin etmek zorunda değildir; kullanıcı görüşmeleri, destek talepleri ve kullanım verileri karar için girdi olur. Önceliklendirme kriterlerini ekiple paylaşmak, sıralamanın gerekçesini anlaşılır kılar ve tartışmayı kısaltır.

Sık yapılan hatalar ve oturum kolaylaştırma

• Backlog'un tamamını ayrıntılandırmak; yalnızca yakın dönemde işlenecek maddeleri hazırlamak yeterlidir.
• Product Owner'ın maddeleri tek başına hazırlayıp ekibe hazır sunması; ortak anlayış kaybolur.
• Tahmin tartışmasını sayıya kilitlemek ve varsayımları konuşmamak.
• Oturumu sınırsız uzatmak; odak kaybı kaçınılmaz olur.
• Çıktıları kaydetmemek: sorular, kararlar ve sorumlular görünür tutulmalıdır.

Kolaylaştırıcı rolü açısından, her madde için sorulacak kısa bir soru dizisi faydalıdır: Kullanıcı kim? Sorun ne? Başarıyı nasıl anlarız? Daha küçük bölebilir miyiz? Bu sorular tartışmayı çözümden ihtiyaca çeker ve oturumu odakta tutar.

Remote çalışan ekiplerde refinement oturumunu kolaylaştırırken maddeyi önceden yazılı paylaşmak ve oturumda yalnızca soruları tartışmak süreyi verimli kullanır. Oturum sonunda her madde için tek satırlık bir durum notu bırakın: hazır, soru bekliyor ya da yeniden bölünecek.

Bu beceriyi Mindset programlarında nerede çalışırsınız?

"Backlog Refinement Pratikleri" programının modül başlıkları backlog nedir ve refinement neden gereklidir, kaliteli user story yazımı, kabul kriterleri ve Definition of Ready, tahminleme yöntemleri, önceliklendirme ve backlog sıralaması ile refinement oturumu kolaylaştırmadır.