Ürün Backlog'u ve Kullanıcı Hikayeleri
Ürünün yol haritası netleşti, ekip artık günlük ritmi de biliyor. Peki her sprint'te ekip tam olarak neyi geliştirecek, ve bu iş bir gecede nasıl anlaşılır ve önceliklendirilir hale gelecek? Cevap: Ürün Backlog'u ve onun temel yapı taşı olan kullanıcı hikayeleri.
Ürün Backlog'u nedir?
Ürün Backlog'u, bir ürüne dair yapılması gereken her şeyin yer aldığı, önceliklendirilmiş, canlı bir listedir. İçinde özellikler, iyileştirmeler, hata düzeltmeleri ve teknik işler bulunur. Backlog asla "bitmiş" sayılmaz; Ürün Sahibi tarafından sürekli güncellenir, yeniden sıralanır ve inceltilir.
- Üstte yer alan maddeler: detaylı, küçük, bir sonraki sprint'e hazır.
- Altta yer alan maddeler: kaba taslak, büyük, henüz netleşmemiş fikirler.
Bu şekle backlog inceltme (grooming/refinement) denir ve ekip bunu düzenli olarak, genelde sprint ortasında kısa oturumlarla yapar.
Kullanıcı hikayesi nedir?
Backlog maddeleri çoğunlukla kullanıcı hikayesi formatında yazılır. Klasik kalıp şöyledir:
"[Kullanıcı tipi] olarak, [istediğim şey]i istiyorum, çünkü [bundan elde edeceğim fayda]."
Örnek: "Bir müşteri olarak, siparişimin kargo durumunu anlık takip etmek istiyorum, çünkü ürünümün ne zaman geleceğini bilmek istiyorum."
Bu format önemlidir çünkü teknik bir görev tanımı değil, kullanıcı değeri odaklıdır. Ekip "ne yapılacağını" değil, "neden yapıldığını" da görür; bu da doğru çözümü bulmayı kolaylaştırır.
INVEST kriterleri
İyi bir kullanıcı hikayesi INVEST kriterlerini karşılar:
| Harf | Anlamı | Kısaca |
|---|---|---|
| I | Independent (Bağımsız) | Diğer hikayelere sıkı bağımlı olmamalı |
| N | Negotiable (Tartışılabilir) | Kesin sözleşme değil, konuşmaya açık bir özet |
| V | Valuable (Değerli) | Kullanıcıya veya işe somut değer katmalı |
| E | Estimable (Tahmin edilebilir) | Ekip büyüklüğünü kabaca tahmin edebilmeli |
| S | Small (Küçük) | Bir sprint içinde bitecek boyutta olmalı |
| T | Testable (Test edilebilir) | "Tamamlandı" olduğunu gösterecek net bir kriter olmalı |
Kabul kriterleri
Her hikayeye eklenen kabul kriterleri, hikayenin ne zaman "bitti" sayılacağını netleştirir. Örneğin kargo takibi hikayesi için: "Kullanıcı sipariş sayfasında güncel kargo durumunu görebilmeli" ve "Durum bilgisi en geç 5 dakikada bir güncellenmeli" gibi somut, test edilebilir cümleler yazılır. Bu kriterler olmadan ekip ile Ürün Sahibi arasında "bitti mi, bitmedi mi" tartışmaları çıkar.
Önceliklendirme nasıl yapılır?
Ürün Sahibi, backlog'u değer, aciliyet ve risk dengesine göre sıralar. Sık kullanılan basit bir yaklaşım, maddeleri değer ve çaba eksenlerinde değerlendirmektir: yüksek değer, düşük çaba gerektiren işler her zaman öne alınır.
Backlog ve kullanıcı hikayeleri sağlam kurulduğunda, sprint planlama toplantıları çok daha hızlı ve isabetli ilerler; çünkü ekip neyi, neden yaptığını zaten biliyor.
Bir sonraki derste bu iyi hazırlanmış backlog'un sprint içinde nasıl planlanacağını ve Sprint Planlama toplantısının nasıl işlediğini ele alacağız.
Bu dersi kayıt olmadan izleyebilirsin. İlerlemeni kaydetmek, sertifika almak ve puan tablosuna girmek için ücretsiz üye ol: Kayıt Ol