User Story Nasıl Yazılır? Şablon, Örnek ve Kabul Kriteri

User story, bir işi kullanıcının gözünden anlatan kısa cümledir. Amacı işi tarif etmek değil, konuşmayı başlatmaktır. Bu yüzden iyi bir hikâye teknik şartname gibi görünmez; problemi ve beklenen faydayı taşır, çözümü ekibe bırakır.

Klasik şablon

Kim olarak [kullanıcı tipi] ne isterim [istenen şey] çünkü [elde edilecek fayda]

Örnek: Sık seyahat eden bir kullanıcı olarak son aramalarımı kaydetmek isterim, çünkü her seferinde aynı bilgileri girmek zaman kaybettiriyor.

Üçüncü satır en sık atlanan ve en değerli satırdır. "Çünkü" kısmı olmadan yazılan hikâye, gerekçesi bilinmeyen bir talep listesine dönüşür ve önceliklendirmesi imkânsızlaşır.

Kötü ve iyi örnek

Kötü: "Kullanıcı tablosuna favoriler kolonu eklensin." Bu bir çözüm talimatıdır; kullanıcı yok, fayda yok, tartışmaya kapalı.

İyi: "Düzenli alışveriş yapan bir kullanıcı olarak beğendiğim ürünleri işaretlemek isterim, çünkü sonra tekrar aramak istemiyorum." Aynı iş, ama problem görünür. Ekip favoriler tablosu yerine daha iyi bir çözüm önerebilir.

Kabul kriteri nasıl yazılır?

Hikâye niyeti, kabul kriteri sınırı belirler. En kullanışlı format koşul temellidir:

• Verilen durum: kullanıcı giriş yapmış ve ürün sayfasında
• Eylem: kalp simgesine dokunur
• Beklenen sonuç: ürün favorilere eklenir, simge dolu görünür, çevrimdışıyken de listede kalır

Kriter yazarken mutlu senaryo yetmez. Hata durumu, boş durum ve yetkisiz durum yazılmazsa geliştirme sırasında tahmin edilir ve tahminler tutmaz.

INVEST kontrol listesi

İyi bir hikâye şu altı özelliği taşır: bağımsız (Independent), tartışılabilir (Negotiable), değerli (Valuable), tahmin edilebilir (Estimable), küçük (Small), test edilebilir (Testable). Bir hikâye sprint'e sığmıyorsa küçük değildir; parçalayın. Neyi test edeceğinizi yazamıyorsanız test edilebilir değildir; kriterleri netleştirin.

Hikâyelerin toplandığı yerin nasıl yönetildiği için backlog yazısına, işi anlatma pratiğinin genel hâli için iyi brief nasıl yazılır yazısına bakın.

Hikâye bir arayüz değişikliği içeriyorsa, tarif etmek yerine çizmek çoğu zaman daha hızlıdır; wireframe rehberine bakabilirsiniz.

Sıkça sorulan sorular

Her iş user story olmak zorunda mı?

Hayır. Teknik borç ödemesi, altyapı taşıması veya hata düzeltmesi hikâye formatına zorlanınca gülünç olur ("Sistem olarak loglarımın dönmesini isterim"). Bu işler kendi başlıklarıyla yazılabilir.

Hikâyeyi kim yazar?

Genelde Product Owner başlatır ama en iyi hikâyeler ekiple birlikte netleşir. Tek başına yazılıp masaya bırakılan hikâye, konuşmayı başlatmak yerine sipariş fişine dönüşür.

Epic ile story farkı ne?

Epic, tek sprinte sığmayan büyük iştir ve birden fazla hikâyeye bölünür. "Ödeme sistemi" bir epic, "kredi kartı bilgisi kaydetme" bir hikâyedir.

User story ile use case farkı ne?

Use case, bir işlemi baştan sona tüm adımları ve alternatif senaryolarıyla anlatan daha resmi, daha kapsamlı bir belgedir. User story bilinçli olarak eksiktir; tüm detayı önceden yazmak yerine konuşmayı tetikler. Ağır süreç gerektiren, çok paydaşlı sistemlerde use case; hızlı yinelenen ürün geliştirmede user story daha doğal çalışır.

Story point nasıl tahmin edilir?

Genelde göreli karşılaştırmayla: yeni hikâye, daha önce yapılmış ve büyüklüğü bilinen bir hikâyeyle kıyaslanır ("bu, geçen sprintteki favoriler işinin yaklaşık iki katı"). Fibonacci benzeri bir ölçek (1, 2, 3, 5, 8...) kullanmak, sahte kesinlik hissini önler; büyük sayılar arasındaki fark bilerek kabalaşır.