Product Backlog ve Product Goal: Ne Yapıyoruz, Neden Yapıyoruz?

Sürüm notu: Bu yazı Scrum Guide 2020'yi (Kasım 2020, Ken Schwaber ve Jeff Sutherland) esas alır; Kasım 2026 itibarıyla scrumguides.org'daki güncel resmi sürüm hâlâ budur. Örnek board GitHub Projects'in tablo görünümüyle kurgulandı; aynı yapı herhangi bir araçta kurulabilir.

Önce Tahmin Et

Bookstore'un backlog'unda 64 item var. Ekip her item'a bir öncelik etiketi koymuş: 38 tanesi P1 (Priority 1, en yüksek öncelik), 19 tanesi P2 (Priority 2), 7 tanesi P3 (Priority 3). Selin'in önünde dört aday duruyor: "İade talebi oluşturma ekranı" (P1, müşterilerin en çok istediği şey), "Kargo firmasının iade etiketi API'sini (Application Programming Interface) denemek" (P2, kimse daha önce kullanmadı), "Sipariş geçmişi sayfasında yanlış tarih görünüyor" (P1 bug) ve "OrderService'teki 900 satırlık method'u bölmek" (P3, teknik borç).

Bir sonraki Sprint için en üstte hangisi olmalı? Ve 38 tane P1'in olduğu bir listede "P1" etiketi Selin'e ne kadar bilgi veriyor? Tahminini yaz, sonra Guide'ın neden "prioritized" değil "ordered" dediğine bakalım.

Product Backlog: Tek, Sıralı ve Büyüyen Bir Liste

Guide Product Backlog'u ürünü iyileştirmek için gerekenlerin ortaya çıkan (emergent), sıralı listesi olarak tanımlıyor ve ekledikleri cümle kritik: Product Backlog, Scrum Team'in üstlendiği işin tek kaynağıdır. Yani ayrı bir bug tracker, ayrı bir "teknik borç listesi" ya da ayrı bir "müdürün istekleri" dosyası yok; Scrum Team'in yapacağı her iş bu listede ve bu listenin sırasında.

"Emergent" kelimesi listenin hiçbir zaman bitmiş olmadığını söylüyor. Bookstore'un backlog'u ilk gün iade akışının kabaca on maddesini içeriyordu; ilk Sprint Review'dan sonra destek ekibinin "iade sebebi listesi" isteği, ikinci Sprint'te kargo API'sinin kısıtları yüzünden üç yeni item eklendi. Liste ürünle birlikte büyüyor, değişiyor, bazen küçülüyor.

"Ordered" kelimesi ise 2011'den beri Guide'da. Revizyon notları "prioritized" yerine "ordered" denmesinin sebebini Product Owner'a kendi koşullarında değeri optimize etmek için esneklik vermek olarak açıklıyor. Öncelik etiketi bir item hakkında tek başına bir yargıdır; sıra ise item'lar arasındaki bir karardır. 38 tane P1'in olduğu listede etiket karar vermiyor, kararı erteliyor. Sıralı listede ise iki item aynı yerde duramaz; biri diğerinin üstündedir.

Sırayı Ne Belirler?

Sıralama yalnız "en değerli olan en üstte" demek değil. Bookstore'da Selin dört şeye birlikte bakıyor:

• Değer: Item yapılınca kim, ne kadar fayda görür? İade ekranı destek ekibine haftada yaklaşık 120 e-postadan kurtulma vaat ediyor.
• Risk ve öğrenme: Kargo API'sini kimse kullanmadı; bilinmezliği erken öğrenmek, üzerine kurulacak işi ucuzlatır. Değeri düşük görünen bir deneme, riski yüksek olduğu için üste çıkabilir.
• Bağımlılık: İade ekranı, iade etiketinin üretilebildiğini varsayıyor; etiket çalışmazsa ekran yarım kalır.
• Maliyet ve beklemenin bedeli: 900 satırlık method her iade değişikliğinde dokunulan yer; dokunuldukça yavaşlatıyor. Yanlış tarih bug'ı ise her gün yeni müşteri şikâyeti üretiyor.

Bu dört boyutun formüle dökülmüş hâlleri (RICE yani Reach, Impact, Confidence, Effort; Cost of Delay; Kano) Product Management'a Giriş serisinin "Prioritization Framework'leri: RICE, MoSCoW, Kano ve Cost of Delay" yazısında. Scrum burada belirli bir tekniği şart koşmuyor; yalnızca kararın Product Owner'da olduğunu ve sonucun görünür bir sıra olduğunu söylüyor.

Selin'in kararı: en üste kargo API'sini denemek için iki günlük bir spike, hemen altına yanlış tarih bug'ı (küçük ve her gün maliyet üretiyor), sonra iade ekranı. Teknik borç item'ı iade ekranının içine bağlandı: ekran, method'un ilgili kısmı bölünmeden yapılamayacağı için Developers bu işi ekranın planına dahil etti. Bug, spike ve teknik borç aynı listede; çünkü hepsi ekibin kapasitesinden yiyor ve sıralanmadıkça görünmüyor.

Product Goal: Listenin Neden Var Olduğu

2020 sürümünün en önemli eklemelerinden biri Product Goal. Guide her artifact'a bir commitment bağlıyor ve Product Backlog'un commitment'ı Product Goal. Tanım şu: ürünün gelecekteki bir durumunu tarif eden, Scrum Team'in planlarken hedef aldığı bir amaç. Product Goal Product Backlog'un içinde durur; listenin geri kalanı o hedefi neyin gerçekleştireceğini tanımlamak için ortaya çıkar.

Guide iki kuralı daha ekliyor. Product Goal Scrum Team'in uzun vadeli amacıdır ve ekip bir sonrakine geçmeden önce mevcut amacı ya gerçekleştirmeli ya da bilinçli olarak bırakmalıdır. Yani aynı anda üç Product Goal yok. İkincisi, "ürün" tanımı: değer teslim etmek için bir araç, net bir sınırı, bilinen stakeholder'ları ve iyi tanımlanmış kullanıcıları ya da müşterileri olan bir şey. Bu tanım "ürün" kelimesini yalnız yazılım paketiyle sınırlamıyor; bir hizmet ya da daha soyut bir şey de olabilir.

Bookstore için iki aday Product Goal karşılaştıralım. Birincisi: "İade modülünü tamamlamak." Bu bir hedef değil, bir iş paketinin adı; ne zaman bittiğini kimse ölçemez ve ekip "modül" kelimesinin içine ne koyarsa o olur. İkincisi: "Kayıtlı müşteriler teslim edilmiş siparişlerinin iadesini destek ekibine yazmadan başlatıp takip edebilsin; iade için açılan destek e-postası haftada 120'den 20'nin altına insin." Bu ikincisi ürünün gelecekteki bir durumunu anlatıyor, gerçekleşip gerçekleşmediği ölçülebiliyor ve backlog'daki her item için "bu bizi oraya yaklaştırıyor mu?" sorusunu sormayı mümkün kılıyor. Output yerine outcome odaklı hedef yazımı Product Management'a Giriş serisinin "Output Değil Outcome: Problem Tanımı, Hipotez ve Jobs to Be Done" yazısında ayrıntılı.

Refinement Bir Event Değil

Product Backlog refinement, item'ları daha küçük ve daha net item'lara bölme ve tanımlama işi. Guide bunu sürekli bir aktivite olarak tanımlıyor ve beş event'in arasında saymıyor. Refinement'la item'lara açıklama, sıra ve büyüklük gibi ayrıntılar eklenir; bu özellikler işin alanına göre değişir.

Büyüklük konusunda Guide net: işi yapacak Developers büyüklükten de sorumludur. Product Owner, trade-off'ları anlamalarına ve seçmelerine yardım ederek Developers'ı etkileyebilir ama boyutu o belirlemez. Boyutlandırmanın tekniği (story point, item sayısı, T-shirt boyutu) ilerideki Estimation ve Planning serisinin konusu; item'ın iyi yazılması ve acceptance criteria ise ilerideki Requirements Analysis serisinin.

2017 Guide'ı refinement'ın genellikle Development Team kapasitesinin yüzde 10'undan fazlasını tüketmediğini söylüyordu; 2020 sürümü bu sayıyı çıkardı. Bookstore ekibi yine de bir başlangıç noktası olarak her Sprint'in ikinci haftasında 90 dakikalık bir oturum yapıyor, ama asıl refinement gün içinde oluyor: Ayşe kargo API'sinin dokümanını okurken iade etiketi item'ını ikiye bölüyor ve board'da güncelliyor. Oturum takvimde bir alışkanlık; refinement'ın kendisi bir event değil.

Definition of Ready: Faydalı mı, Kapı Bekçisi mi?

Guide'da Definition of Ready diye bir şey yok. 2013 sürümü "Ready" kelimesini, bir Sprint içinde Done yapılabilecek item'lar için bir durum olarak tanıtmıştı; 2020 sürümü aynı fikri küçük harfle tutuyor: bir Sprint içinde Done yapılabilecek item'lar Sprint Planning'de seçilmeye hazır kabul edilir ve bu şeffaflığa genellikle refinement sonrasında ulaşırlar. Bir kontrol listesi ya da commitment tanımlamıyor.

Birçok ekip yine de bir Definition of Ready yazıyor. Faydalı olduğu durum: ekip aynı tip sürprizle tekrar tekrar karşılaşıyorsa (örneğin dış bir API'nin sözleşmesi bilinmeden item Sprint'e alınıyor ve ortada kalıyorsa) "dış bağımlılığın sözleşmesi biliniyor" maddesi ekip için hatırlatıcıdır. Zararlı olduğu durum: liste uzayıp bir kapıya dönüşür. "Tasarım tamam, bütün acceptance criteria yazılı, estimation yapılmış, test senaryoları hazır" gibi bir liste, item'ın Sprint'e girmeden önce bütün analizinin bitmesini şart koşar. Bu da Sprint'i analizden sonra gelen bir uygulama aşamasına, yani küçük bir waterfall'a çevirir; Developers ile Product Owner'ın Sprint içindeki konuşması da kaybolur. Guide'ın Sprint için söylediği "öğrenildikçe kapsam Product Owner'la netleştirilebilir ve yeniden konuşulabilir" cümlesi bunun tam tersini istiyor.

Bookstore'un kuralı kısa: Definition of Ready yok; ama Sprint Planning'de bir item için "bunu bu Sprint'te Done yapabilir miyiz?" sorusuna dürüst cevap verilemiyorsa item seçilmiyor ve refinement'a dönüyor.

Bookstore Backlog'unun İlk Sekiz Satırı

GitHub Projects'te ekip tek bir tablo görünümü kullanıyor; satırların sırası elle sürüklenerek belirleniyor ve bir "Type" alanı item'ın feature, bug, spike ya da teknik borç olduğunu gösteriyor. Sprint Planning'den önceki hâli:

"Neden burada" sütunu ekibin en çok işine yarayan şey oldu. Sıranın gerekçesi yazılı olduğunda, Sprint Review'da bir stakeholder "e-posta bildirimi neden bu kadar aşağıda?" diye sorduğunda tartışma kişilerden çıkıp gerekçeye dönüyor; Guide'ın Product Owner için istediği "şeffaf, görünür ve anlaşılır" backlog da bu.

Üretimde Dikkat

Product Backlog'un sağlığını ölçmek için Bookstore üç sayıya bakıyor. Birincisi, listenin uzunluğu ve yaşı: altı aydan uzun süredir dokunulmamış item oranı yüzde 40'ı geçtiğinde Selin bir temizlik yapıyor ve bu item'ların çoğunu kapatıyor. Uzun ve eski bir liste transparency'yi azaltır; kimse 400 satırı okumaz. İkincisi, en üstteki item'ların hazırlığı: listenin ilk on item'ının kaçı bir Sprint içinde Done yapılabilecek kadar küçük ve net? Bu sayı Sprint Planning'in ne kadar süreceğini doğrudan belirliyor. Üçüncüsü, liste dışı iş: Sprint içinde backlog'a hiç girmeden yapılan "küçük" işlerin sayısı. Bu sayı yükseliyorsa Product Backlog işin tek kaynağı değil demektir.

Ölçekte aynı ürün üzerinde birden çok ekip varsa Guide'ın cevabı yine tek Product Backlog. Her ekibin kendi backlog'unu tutması, ekipler arası bağımlılıkları ve sıralama kararlarını görünmez kılar.

Sık Düşülen Tuzaklar

Her şeyin P1 olması. Öncelik etiketleri karar vermenin yerine geçtiğinde Product Owner'ın asıl işi olan sıralama yapılmaz; Developers Sprint Planning'de en tanıdık ya da en kolay P1'i seçer.

Birden çok backlog. Bug'lar ayrı bir sistemde, teknik borç bir wiki sayfasında, müdürün istekleri e-postada. Sonuç: ekibin kapasitesinin ne kadarının nereye gittiği görünmez ve Sprint Goal'ler sürekli "beklenmedik" işle bozulur.

Product Goal'ü bir feature listesi ya da slogan olarak yazmak. "Dünyanın en iyi kitapçı deneyimi" ölçülemez; "İade modülü" ise bir iş paketidir. İkisi de backlog'daki bir item'ın hedefe yaklaştırıp yaklaştırmadığını sormaya izin vermez.

Refinement'ı yalnız bir toplantıya hapsetmek ve Definition of Ready'yi kapıya çevirmek. İkisi de Sprint'i analiz ile uygulamanın ayrıldığı bir hatta dönüştürür.

Küçük Bir Deneme

★☆☆ Ekibinin backlog'undaki ilk on item'ı al ve her birinin yanına bir cümlelik "neden burada" gerekçesi yaz. Gerekçe yazamadığın item'ların sayısı, sıranın ne kadarının gerçekten bir karar olduğunu gösterir.

★★☆ Mevcut ürününüz için bir Product Goal yaz: ürünün gelecekteki bir durumunu anlatsın ve gerçekleşip gerçekleşmediği ölçülebilsin. Sonra backlog'daki ilk yirmi item'dan hangilerinin bu hedefe katkısı olmadığını işaretle.

★★★ Ekibin Sprint içinde backlog'a hiç girmeden yaptığı işleri bir Sprint boyunca bir yere not et (destek talepleri, "hızlıca bakar mısın" istekleri, production düzeltmeleri). Sprint sonunda bunların toplam süresini Sprint Goal'e harcanan süreyle karşılaştır ve bu işin backlog'da görünür olması için bir öneri getir.

Bookstore'un backlog'u sıralı ve bir Product Goal'ü var. Bir sonraki yazıda Sprint'in kendisine ve Sprint Planning'e geçiyoruz: Guide'ın üç sorusu (why, what, how), Sprint Goal commitment'ı ve 2011'de "commit" kelimesinin neden "forecast" olduğu.