Product Backlog ve Sprint Backlog: Kim Yönetir, Ne Zaman Değişir?

Ortak zemin: Scrum'ın şeffaflık artifaktları

Scrum Rehberi'nde Product Backlog, Sprint Backlog ve Artım (Increment) olmak üzere artifaktlar tanımlanır. Artifaktlar işi ve değeri görünür kılmak için vardır; takım ve paydaşlar aynı bilgiye bakarak denetim ve uyarlama yapar. Her artifaktın kendine bağlı bir taahhüdü vardır: Product Backlog için Ürün Hedefi, Sprint Backlog için Sprint Hedefi, Artım için Done tanımı.

Product Backlog ile Sprint Backlog aynı işin farklı zaman ufuklarındaki görünümleridir. Product Backlog ürünün geleceğine dair "neye ihtiyaç var" sorusunu, Sprint Backlog ise "bu Sprint'te neyi, nasıl ve neden yapacağız" sorusunu yanıtlar. Biri ürünün uzun soluklu yol haritasıdır, diğeri geliştiricilerin kısa vadeli çalışma planıdır.

Ölçüt ölçüt Product Backlog ve Sprint Backlog

• Tanım: Product Backlog / ürünü iyileştirmek için gerekenlerin ortaya çıkan (emergent), sıralı listesi. Sprint Backlog / geliştiriciler tarafından ve geliştiriciler için hazırlanan Sprint planı.
• Hesap verebilirlik: Product Backlog / Product Owner, etkin Product Backlog yönetiminden hesap verebilirdir; işi başkalarına devretse de hesap verebilirlik onda kalır. Sprint Backlog / geliştiriciler (Developers).
• Taahhüt: Product Backlog / Ürün Hedefi. Sprint Backlog / Sprint Hedefi.
• İçerik: Product Backlog / özellikler, hata düzeltmeleri, teknik işler, araştırma işleri gibi Product Backlog öğeleri. Sprint Backlog / Sprint Hedefi, bu Sprint için seçilen Product Backlog öğeleri ve Artımı teslim etmek için uygulanabilir plan.
• Zaman ufku: Product Backlog / ürün yaşadığı sürece. Sprint Backlog / yalnızca ilgili Sprint boyunca.
• Değişim: Product Backlog / sürekli değişir; inceltme (refinement) ile öğeler bölünür, ayrıntılanır, yeniden sıralanır. Sprint Backlog / geliştiriciler öğrendikçe Sprint boyunca güncellenir; kapsam netleştirilmesi gerekirse Product Owner ile müzakere edilir, Sprint Hedefi korunur.
• Ayrıntı düzeyi: Product Backlog / üstteki öğeler ayrıntılı, alttakiler kaba. Sprint Backlog / günlük ilerlemeyi görünür kılacak kadar ayrıntılı.

Product Backlog nasıl yönetilir?

Product Owner'ın işi, listeyi bir istek kutusu olmaktan çıkarıp değeri en yüksek işin önde olduğu bir yol haritasına dönüştürmektir. Bunun için: • Ürün Hedefini netleştirmek ve öğelerin bu hedefle ilişkisini görünür kılmak. • Öğeleri değer, risk, bağımlılık ve öğrenme ihtiyacına göre sıralamak. • Paydaş taleplerini dinlemek ama her talebi listeye almamak; "hayır" demek de backlog yönetiminin parçasıdır. • İnceltme ile üstteki öğeleri Sprint Planlama'da seçilebilecek kadar küçük ve anlaşılır hale getirmek.

İnceltme sürekli bir etkinliktir: öğelere açıklama, sıra ve büyüklük gibi ayrıntılar eklenir. Büyüklük tahminini işi yapacak geliştiriciler yapar. Kabul kriterleri ve gerekiyorsa takımın kendi belirlediği hazır olma ölçütleri bu aşamada şekillenir.

Sprint Backlog nasıl oluşur ve yaşar?

Sprint Backlog, Sprint Planlama'da doğar. Bu etkinlikte Scrum Takımı Sprint'in neden değerli olduğunu konuşur ve Sprint Hedefini belirler; geliştiriciler Product Owner ile birlikte Product Backlog'dan hangi öğelerin bu Sprint'e alınacağını seçer ve seçilen işin nasıl yapılacağını planlar. Planlama sırasında öğeler genellikle görevlere bölünür.

Sprint boyunca Sprint Backlog geliştiricilerin canlı çalışma planıdır. Yeni bir teknik ihtiyaç ortaya çıktığında görev eklenir, gereksiz olduğu anlaşılan görev çıkarılır. Günlük Scrum, Sprint Hedefine doğru ilerlemenin denetlendiği ve Sprint Backlog'un gerekirse uyarlandığı etkinliktir. Sprint sona erdiğinde Sprint Backlog'un işi biter; tamamlanmayan öğeler Product Backlog'a döner ve sıraları yeniden değerlendirilir.

Örnek: bir mobil bankacılık ekibinde backlog akışı

Örneğin bir mobil bankacılık ürününün Ürün Hedefi "bireysel müşterilerin şubeye gitmeden kredi kartı başvurusunu tamamlaması" olsun. Product Backlog'da kimlik doğrulama adımı, gelir beyanı ekranı, başvuru durum takibi, erişilebilirlik düzeltmeleri, bir güvenlik açığı giderimi ve kampanya bildirimi gibi öğeler sıralıdır.

Sprint Planlama'da takım Sprint Hedefini "müşteri kimlik doğrulamayı uçtan uca tamamlayabilsin" olarak belirler. Sprint Backlog'a kimlik doğrulama öğesi ve ilgili güvenlik düzeltmesi alınır; geliştiriciler bunları servis entegrasyonu, ekran geliştirme, otomatik test ve güvenlik kontrolü gibi görevlere böler.

Sprint ortasında entegrasyon servisinin beklenenden karmaşık olduğu anlaşılır. Geliştiriciler yeni görevler ekler ve Product Owner ile konuşarak ekran animasyonlarını sonraki Sprint'e bırakır. Sprint Hedefi değişmez; değişen, hedefe ulaşmanın planıdır.

Hangi soru için hangi listeye bakılır?

Günlük çalışmada doğru listeye bakmak, gereksiz tartışmaları önler: • "Bu özellik ne zaman gelir?" sorusu Product Backlog'un sırasına ve Ürün Hedefine bakılarak yanıtlanır; Product Owner'ın alanıdır. • "Bu Sprint'te Sprint Hedefine ulaşacak mıyız?" sorusu Sprint Backlog'daki ilerlemeye bakılarak yanıtlanır; geliştiricilerin alanıdır. • "Yeni gelen acil talep ne olacak?" sorusu önce Product Backlog'da sıralanarak ele alınır. Sprint Hedefini anlamsız kılacak kadar kritikse, Sprint'i iptal etme yetkisi yalnızca Product Owner'dadır. • "Paydaşa yol haritası nasıl gösterilir?" sorusu Product Backlog üzerinden, Ürün Hedefiyle ilişkilendirilerek yanıtlanır; Sprint Backlog dış paydaş sunumu için değil, takımın kendi planı içindir.

Bu ayrım, Product Owner'ın "ne ve neden", geliştiricilerin ise Sprint içindeki "nasıl" üzerindeki karar alanını korur.

Sık yapılan hatalar

• Sprint Backlog'u yöneticinin atadığı iş listesi gibi görmek: Sprint Backlog geliştiricilere aittir; kimin hangi görevi alacağına da onlar karar verir.
• Sprint'e Sprint Hedefi olmadan girmek: hedefsiz bir Sprint Backlog, birbirinden bağımsız görevler yığınına döner ve kapsam müzakeresi için ölçüt kalmaz.
• Product Backlog'u sınırsız büyütmek: hiç ele alınmayacak öğeler listeyi okunmaz hale getirir, gerçek öncelikleri gizler.
• Sprint ortasında Product Owner'ın ya da paydaşların doğrudan Sprint Backlog'a iş eklemesi: yeni talepler Product Backlog'a girer ve sıralanır.
• İnceltmeyi atlamak: hazırlıksız öğelerle girilen Sprint Planlama uzar, tahminler güvenilmez olur.
• Yarım kalan işi "neredeyse bitti" diye Artım'a saymak: Done tanımını karşılamayan iş Artım'ın parçası değildir.

Mindset programlarında backlog yönetimi

Backlog Refinement Pratikleri eğitimi backlog'un ne olduğu ve inceltmenin neden gerektiğinden başlar; kaliteli kullanıcı hikâyesi yazımı, kabul kriterleri ve Definition of Ready, tahminleme yöntemleri, önceliklendirme ve backlog sıralaması ile inceltme oturumunu kolaylaştırma modüllerini içerir.

Product Owner hesap verebilirliğine hazırlananlar için PSPO I Product Owner Hazırlık eğitiminde ürün vizyonu ve Ürün Hedefi, ürün birikimi ve önceliklendirme, değer maksimizasyonu modülleri vardır. Agile (Scrum) Ortamında İş Analizi Eğitimi ise ürün backlog yönetimi ile sprint planlama ve gereksinim akışını iş analisti gözüyle ele alır.