Epic'leri sprint'e hazir hikayelere nasil bolunur

Buyuk bir yapisan notu birden fazla kucuk parcaya ayiran, bir epic'in yonetilebilir kullanici hikayelerine bolunme surecini temsil eden beyaz tahta basinda agile ekip Backlog'unuzda duran bir epic, is degildir. Icinde bir yerlerde is olduguna dair bir vaat niteligindedir. Ekibinizin tek bir sprint icinde tahmin edip teslim edebilecegi hikayelere bolunene kadar, sadece hirs dolu bir yer tutucudur. Cogu ekip bunu bilir. Takildiklari yer asil bolme islemidir. Epic tek buyuk bir sey gibi hissedilir ve onu parcalama girisimlerinin her biri ya anlamli olamayacak kadar kucuk ya da bir sprint'e sigamayacak kadar buyuk parcalar uretir. Bu rehber, bolmeyi temiz yapan kaliplari ve teknikleri kapsar.

Bir hikayeyi "sprint'e hazir" yapan nedir

Sprint'e hazir bir hikaye su kriterleri karsilar:

Yeterince kucuk bir sprint icinde tamamlanabilir (ideal olarak 1-5 story point)
Bagimsiz olarak teslim edilebilir, yani diger hikayelerin once bitmesine bagli degildir
Dikey dilimli, sadece bir backend parcasi veya sadece bir arayuz degil, uctan uca islevselligin ince bir dilimini sunar
Tahmin edilebilir, ekibiniz tarafindan planning poker oturumunda 15 dakikalik bir tartisma olmadan
Test edilebilir, acik bir gecti/kaldi kosulu ile

INVEST kriterleri ile tanisiyorsaniz, ayni fikir budur. Amac, uzerinde calisma baslatilabilecek kadar somut hissettiren hikayelerdir.

Tahmin testi

Ekibiniz planning poker oynuyorsa ve tahminler uc veya daha fazla degere yayiliyorsa (ornegin bir 3, bir 8 ve bir 13), hikaye muhtemelen daha fazla bolunmeye ihtiyac duyuyordur. Genis yayilimlar bir sinyaldir, tartisarak cozulecek bir sorun degil.

Epic'leri bolmek icin 6 kalip

Bir epic'i bolmenin tek dogru yolu yoktur. Ancak bu alti kalip cogu durumu kapsar. Sirayla deneyin. Uyan ilk kalip genellikle en temiz hikayeleri uretir.

1. Is akisi adimina gore bolme

Cogu epic, cok adimli bir sureci tanimlar. Her adim kendi hikayesi olabilir. Epic: "Bir musteri olarak, internetten bir urun satin almak istiyorum."

Hikaye	Aciklama
Urunlere goz at	Musteri filtreleme ile bir urun katalogunu goruntuleyebilir
Sepete ekle	Musteri alisveris sepetine urunler ekleyebilir
Odeme yap	Musteri kargo ve odeme bilgilerini girebilir
Siparis onayi	Musteri satin alma sonrasi bir onay e-postasi alir

Her hikaye bagimsiz olarak degerlidir. Urunlere goz atabilen bir musteri, odeme islevi henuz yokken bile deger elde eder.

2. Is kuralina gore bolme

Bir epic dallanma mantigi veya birden fazla kurala sahipse, her kural dogal bir bolme noktasidir. Epic: "Bir kullanici olarak, sistemin kargo ucretlerini hesaplamasini istiyorum."

50$ uzerindeki siparisler icin ucretsiz kargo
Standart yurt ici kargo icin sabit 5$ ucret
Ekspres kargo icin gercek zamanli tasiyici ucretleri
Gumruk tahmini ile uluslararasi kargo

En basit kuraldan (sabit ucret) baslayin ve sonraki sprint'lerde karmasiklik katmanlarini ekleyin.

3. Kullanici turune gore bolme

Farkli kullanicilar ayni ozellikle farkli sekilde etkilesiyorsa, her bakis acisi bir hikayedir. Epic: "Bir kullanici olarak, ekip uyelerini yonetmek istiyorum."

Bir yonetici olarak, e-posta ile yeni uyeler davet etmek istiyorum
Bir yonetici olarak, ekipten uye cikarmak istiyorum
Bir uye olarak, ekibimde kimlerin oldugunu gormek istiyorum
Bir sahip olarak, sahipligi baska bir yoneticiye devretmek istiyorum

4. Mutlu yol ve uc durumlara gore bolme

Once basit senaryoyu olusturun. Hatalari, uc durumlari ve dogrulamalari takip eden hikayelerle ele alin. Epic: "Bir kullanici olarak, profil fotografi yuklemek istiyorum."

Mutlu yol: 5MB'nin altinda bir JPEG veya PNG yukle ve avatar olarak gor
Uc durum: Dosya cok buyukse veya yanlis formattaysa hata goster
Uc durum: Kaydetmeden once gorseli kirp ve yeniden boyutlandir
Uc durum: Mevcut bir fotoyu sil veya degistir

Bir gelistiricinin beyaz tahtadaki bir semasina baktigi gorsel; epic etiketli buyuk bir kutu, kullanici hikayelerini temsil eden daha kucuk baglantili kutulara bolunuyor ve oklar bagimliliklari gosteriyor

5. Veri turune veya platforma gore bolme

Bir ozellik birden fazla veri turu, platform veya entegrasyona uygulaniyorsa, her biri bir hikayedir. Epic: "Bir kullanici olarak, raporlarimi disa aktarmak istiyorum."

CSV olarak disa aktar
PDF olarak disa aktar
Excel olarak disa aktar
Zamanlanmis bir disa aktarimi e-posta ile gonder

6. Performans veya olcege gore bolme

Yaygin durum icin calisan bir seylerle baslayin. Daha sonra optimize edin. Epic: "Bir kullanici olarak, tum projeler arasinda arama yapmak istiyorum."

Mevcut proje icinde arama (basit sorgu)
Tum projeler arasinda arama (indeksleme gerektirir)
Filtreler ekle (tarih araligi, atanan kisi, durum)
Siz yazarken otomatik tamamlama onerileri

Gercek bir ornek: "kullanici bildirimleri"ni parca parca ayirma

Bunun pratikte nasil gorundugunun bir ornegi. Diyelim ki backlog'unuzda su epic var: "Bir kullanici olarak, benimle ilgili aktiviteler hakkinda bildirim almak istiyorum." Bu cok buyuk. Kaliplari uygulayalim: Once is akisina gore bolun. Bildirim gonderme, alma ve yonetme ayri konulardir. Sonra kanala gore bolun. E-posta, uygulama ici ve push bildirimleri her biri kendi hikayesidir. Her kanalin icinde is kuralina gore bolun. Hangi olaylar bir bildirimi tetikler? Her biri (bir yorumda bahsedilme, bir gorev atanmasi, yaklasan son tarih) bir hikayedir. Son olarak mutlu yolu secin. "Kullanici bir gorev atandiginda uygulama ici bildirim alir" ile baslayin. Bir kanal, bir tetikleyici, tamam. E-posta, push, tercihler ve ozet seceneklerini sonra ekleyin. Sonuc: Uc sprint boyunca backlog'da duran "devasa" olarak tahmin edilmis bir epic yerine, onceliklendirilebilen, tahmin edilebilen ve kademeli olarak teslim edilebilen 8-12 hikaye elde edersiniz.

Dikey dilim kurali

En yaygin bolme hatasi, bir epic'i teknik katmana gore boluktir:

Yatay bolmeyin

"Veritabani semasini olustur" + "API'yi olustur" + "Arayuzu olustur" gorevlerdir, hikaye degil. Hicbiri tek basina deger sunmaz. API hazirsa ama arayuz yoksa hicbir kullanici bundan fayda gormez.

Bunun yerine dikey olarak dilimleyin. Her hikaye, birinin gercekten kullanip test edebilecegi, uctan uca calisan ince bir islevsellik parcasi sunmak icin gereken tum katmanlara dokunmalidir. Bir bildirim ozelligi icin dikey dilim sunlar olabilir: "Kullaniciya bir gorev atandiginda, uygulama ici bir bildirim gorunur." Bu backend'e (olay tetikleyici, bildirim kaydi), API'ye (bildirimleri getirme ucu) ve frontend'e (bildirim rozeti ve listesi) dokunur. Ince ama uctan uca calisir.

Teknik katmana gore yatay bolme ile kullaniciya yonelik islevsellige gore dikey bolme arasindaki farki gosteren sema; dikey yaklasim dogru yontem olarak vurgulanmis

Hikayeler hala cok buyuk oldugunda

Bazen bir epic'i bolersiniz ve ortaya cikan hikayeler hala cok buyuktur. Bazi sinyaller:

Ekip 13+ puan olarak tahmin eder
5'ten fazla kabul kriteri vardir
Aciklama, iki farkli davranisi birbirine baglamak icin "ve" kelimesini kullanir
Birden fazla ekip uyesinin ayni anda uzerinde calismasi gerekir

Bu durumda ayni kaliplari tekrar uygulayin. "Kullanici kargo ve odeme ile odeme yapabilir" hikayesi, "kullanici kargo adresini girebilir" ve "kullanici odeme bilgilerini girebilir" olarak bolunur. Her parca rahatca bir sprint'e sigana kadar devam edin.

'Ve' testi

Hikayeyi sesli okuyun. Iki farkli davranisi birbirine baglayan "ve" iceriyorsa, muhtemelen iki hikayedir. "Bir kullanici olarak, arama sonuclarini filtrelemek ve siralamak istiyorum" pardosu giymis iki hikayedir.

Bolmeyi hizlandirmak icin araclar kullanma

Epic'leri bolme, pratikle gelisen bir beceridir, ancak araclar sureci hizlandirabilir. Kollabe'nin Hikaye Bolucu araci, bir epic aciklamasini alir ve yukaridaki kaliplari kullanarak sprint'e hazir hikayeler uretir. Buyuk bir epic'e bakip nereden keseceginizi bilmediginizde iyi bir baslangic noktasidir. Hikayeleriniz hazir oldugunda, Kullanici Hikayesi Uretici bunlari uygun kabul kriterleri ve standart kullanici hikayesi formatiyla detaylandirmaniza yardimci olabilir. Ardindan bunlari planning poker oturumuna getirerek tahmin edin ve bolmelerin ekibiniz icin gercekten anlamli olup olmadigini dogrulayin.

Sprint planlamasindan once kisa bir kontrol listesi

Bolunmus hikayeleri bir sprint'e almadan once bunlari gozden gecirin:

Her hikaye, kullanicinin gorebilecegi veya etkilesebilecegi bir deger sunar

Hicbir hikaye, ayni sprint'teki tamamlanmamis baska bir hikayeye bagli degildir

Ekip her hikayeyi uzun tartismalar olmadan tahmin edebilir

Her hikaye icin kabul kriterleri tanimlanmistir

Hikayeler dikey olarak dilimlidir, teknik katmana gore bolunmemistir

Orijinal epic'in tam kapsami tum hikayeler arasinda karsilanmaktadir

Altisi da uygunsa, hikayeleriniz sprint planlama icin hazirdir.

Bolmeye baslayin

Alti kalip, bir kural: her hikaye, bir sprint'e sigan dikey bir deger dilimi sunmalidir. Belirsiz bir epic'e bakip takildiginizda, uyan ilk kalibi secin, kesimi yapin ve tahminle dogrulayin. Tahminler hala her yere dagik cikiyorsa, tekrar kesin.

Bir sprint icinde bitirilecek kadar kucuk, ideal olarak 1-5 story point olarak tahmin edilmis. Ekibiniz hikayeleri surekli olarak 1-3 gunde bitiriyorsa, iyi bir noktadasiniz. Tum sprint'i kaplayan hikayeler risklidir cunku surprizler icin yer kalmaz.

Sorun degil. 15-20 hikayeli bir epic, teslimat icin net bir yol haritaniz oldugu anlamina gelir. Acimadan onceliklendirin. Hepsini olusturmak zorunda degilsiniz. Urun sahibi her sprint icin en yuksek degerli hikayeleri secer.

Backlog iyilestirme sirasinda. Sprint planlama cok gec olur cunku o toplantidan once hikayelerin zaten iyilestirilmis ve tahmin edilmis olmasi gerekir. Cogu ekip, epic'leri uzerinde calismayi planladiklari zamandan 1-2 sprint once boler.

Planning poker oynayin. Ekip her hikayeyi hizla tahmin edebiliyorsa ve tahminler birbirine yakin cikiyorsa (bir 2 ve bir 13 yerine, bir 3, bir 5 ve bir 5), bolme ise yariyordur. Genis tahmin yayilimlari hikayenin hala cok belirsiz veya cok buyuk oldugu anlamina gelir.

10/02/2026 tarihinde son güncelleme