Epic mi Kullanıcı Hikayesi mi? Backlog'da Büyük İşi Doğru Dilimlemek

İki kavram aynı eksende: Büyüklük ve belirsizlik

Kullanıcı hikayesi (user story), bir kullanıcının ihtiyacını onun bakış açısından anlatan kısa bir ifadedir. Yaygın kalıbı şöyledir: "Bir [kullanıcı rolü] olarak, [amaç] için [ihtiyaç] istiyorum." İyi yazılmış bir hikaye, ekibin tek bir sprint içinde tamamlayıp çalışır halde gösterebileceği kadar küçüktür ve kabul kriterleriyle birlikte "bitti" sayılacağı koşulları netleştirir.

Epic ise tek bir sprintte bitmeyecek kadar büyük ya da henüz yeterince anlaşılmamış bir iş gövdesidir. Bir epic, ortak bir amaca hizmet eden çok sayıda kullanıcı hikayesine bölünür. "Müşteriler siparişlerini mobil uygulamadan iade edebilsin" bir epic olabilir; "Müşteri olarak, iade sebebini listeden seçebilmek istiyorum ki formu hızlıca doldurabileyim" ise o epicin altındaki hikayelerden biridir.

İki kavram arasındaki ilişki hiyerarşiden çok bir olgunluk sürecidir: Bugün epic olan bir fikir, ekip onu anladıkça ve böldükçe sprint planlamaya hazır hikayelere dönüşür.

Ortak zemin: İkisi de kullanıcı değerini anlatır

Epic ve kullanıcı hikayesi teknik görevler değildir. "Veritabanı tablosu oluştur" ya da "API uç noktası yaz" bir epic de bir hikaye de değildir; bunlar hikayeyi gerçekleştirmek için yapılan görevlerdir. Hem epic hem hikaye, kullanıcıya ya da işe sağlanan bir sonucu anlatmalıdır.

İkisi de Scrum Guide'da tanımlanan resmî ögeler değildir. Scrum yalnızca Product Backlog ögelerinden söz eder; epic ve kullanıcı hikayesi, çevik ekiplerin bu ögeleri yazmak ve gruplamak için yaygın olarak benimsediği tekniklerdir. Bu nedenle ikisinin tanımı ekipten ekibe biraz farklılaşabilir.

İkisi de Product Owner'ın sorumluluğundaki ürün birikiminde yer alır ve önceliklendirilir. Epic daha çok yol haritası ve sürüm planlama düzeyinde, hikaye ise sprint planlama ve günlük çalışma düzeyinde konuşulur.

Ölçüt ölçüt epic ve kullanıcı hikayesi

• Büyüklük: Epic / tek sprintte bitmez, genellikle birkaç sprinte yayılır. Kullanıcı hikayesi / tek sprintte tamamlanabilir.
• Ayrıntı düzeyi: Epic / amaç ve kapsamın ana hatları, varsayımlar, başarı ölçütü. Kullanıcı hikayesi / net rol, ihtiyaç, amaç ve kabul kriterleri.
• Tahmin: Epic / kaba büyüklük (tişört bedeni gibi göreli ölçüler) ya da hiç tahmin edilmez. Kullanıcı hikayesi / story point ya da benzeri birimlerle ekip tarafından tahmin edilir.
• Planlama düzeyi: Epic / yol haritası, çeyreklik ya da sürüm planı. Kullanıcı hikayesi / sprint planlama ve sprint backlog.
• Sahiplik: Epic / Product Owner, genellikle paydaşlarla birlikte. Kullanıcı hikayesi / Product Owner yazar ya da kabul eder, geliştiriciler (Developers) birlikte netleştirir.
• Tamamlanma: Epic / altındaki hikayeler bittiğinde ya da amacına ulaşıldığında kapanır. Kullanıcı hikayesi / kabul kriterleri ve tamamlanma tanımı (Definition of Done) karşılandığında biter.
• Belirsizlik: Epic / yüksek, keşif ve araştırma gerektirebilir. Kullanıcı hikayesi / düşük, ekip ne yapılacağını konuşarak anlamıştır.

Bir epic kullanıcı hikayelerine nasıl bölünür?

Bölmenin amacı işi sadece küçültmek değil, her parçanın kendi başına değer üreten ve gösterilebilen bir dilim olmasıdır. Bunun için işi teknik katmanlara (önce veritabanı, sonra arayüz) değil, kullanıcı akışının dikey dilimlerine ayırmak gerekir.

Yaygın bölme yöntemleri şunlardır: • İş akışı adımlarına göre: İade talebi oluşturma, kargo kodu alma, iade durumunu izleme. • İş kuralı varyasyonlarına göre: Önce yalnız hasarsız ürün iadesi, sonra hasarlı ürün iadesi. • Veri ya da kanal türüne göre: Önce kredi kartıyla ödenmiş siparişler, sonra diğer ödeme yöntemleri. • Basitten karmaşığa: Önce temel akış, sonra istisnalar ve hata durumları. • Performans ya da kaliteyi sonraya bırakarak: Önce çalışan bir çözüm, sonra hızlandırma. • Araştırmayı ayırarak: Belirsiz bir konu varsa önce zaman kutulu bir araştırma (spike), sonra uygulama.

Story mapping bu bölmeyi görsel olarak yapmanın etkili bir yoludur: Kullanıcı yolculuğu yatay eksende, her adımın hikayeleri dikey eksende dizilir ve ilk sürüm için yatay bir dilim seçilir.

İyi bir kullanıcı hikayesinin işaretleri

Çevik toplulukta sık kullanılan INVEST ölçütü, bir hikayenin sprinte hazır olup olmadığını sınamak için pratik bir kontrol listesidir: bağımsız (Independent), pazarlığa açık (Negotiable), değerli (Valuable), tahmin edilebilir (Estimable), küçük (Small) ve test edilebilir (Testable).

Bir hikaye bu ölçütlerin birkaçını karşılamıyorsa, büyük ihtimalle hâlâ bir epic ya da bölünmesi gereken büyük bir hikayedir. Örneğin ekip tahmin yaparken görüşler çok farklıysa ya da kabul kriterleri sayfalar sürüyorsa, hikaye fazla büyüktür.

Örneğin "Müşteri olarak iade yapabilmek istiyorum" ifadesi bir hikaye gibi görünse de kanal, ürün türü, ödeme yöntemi ve kargo entegrasyonu gibi pek çok değişken barındırır. Ekip bunu sprint planlamaya getirdiğinde kapsamı netleştiremiyorsa, ifade aslında bir epictir ve önce bölünmelidir.

Sık yapılan hatalar ve önlemleri

• Epici bir klasör gibi kullanmak: Birbiriyle ilgisiz işleri aynı epic altında toplamak, epicin amacını ve başarı ölçütünü kaybettirir. Her epicin tek bir iş sonucuna bağlı olması gerekir.
• Hikayeleri teknik katmanlara bölmek: "Arka uç" ve "ön yüz" hikayeleri tek başına kullanıcıya değer üretmez; sprint sonunda gösterilecek bir şey kalmaz.
• Hiç kapanmayan epicler: Altına sürekli yeni hikaye eklenen bir epic, ilerlemenin ölçülmesini imkânsız kılar. Amaç karşılandığında epic kapatılmalı, kalan fikirler yeni bir epic olarak değerlendirilmelidir.
• Kalıbı amaçsız doldurmak: "Kullanıcı olarak, butonu istiyorum" cümlesi kalıba uyar ama amacı ("... ki ...") içermediği için konuşmayı başlatmaz.
• Kabul kriterlerini sprint içine bırakmak: Kriterler sprint planlama öncesinde, backlog iyileştirme toplantısında netleşmezse tahminler de güvenilmez olur.

Bu hataların ortak ilacı düzenli backlog iyileştirmedir: Product Owner ve geliştiriciler, sıradaki epicleri birlikte böler ve hikayeleri sprinte hazır hale getirir.

Epic ve hikaye yazımını Mindset programlarında nerede çalışırsınız?

Story Mapping ve Kullanıcı Senaryoları programı story map'in ne olduğu, kullanıcı yolculuğu haritası, kullanıcı senaryoları yazımı, MVP tanımı ve sürüm planlama ile story map atölyesi yürütmeyi kapsar; epiclerin dilimlere ayrılması bu akış içinde uygulanır. Çevik Tahminleme ve Story Points programı ise bölünen hikayelerin Fibonacci dizisi, Planning Poker ve hız (velocity) ile nasıl tahmin edileceğini işler.

Ürün birikimini sahiplenen roller için PSPO I Product Owner Hazırlık programı ürün birikimi ve önceliklendirme, ürün hedefi ve paydaş yönetimi modülleriyle bu çalışmanın Product Owner tarafını tamamlar.