Ana sayfa → Bölüm 08
Epic, Story, Task: İşi Kırmanın Mantığı ve 8 Saat Kuralı
Tahtada bir kart var: “İade talebi oluşturma”. Üç gündür “devam ediyor” sütununda. Sorduğunda alınan cevap hep aynı: “bitmek üzere.” Bu yazı tam olarak o kart hakkında.
- Epic neden, story ne, task nasıl. Üçü aynı şeyin büyüğü küçüğü değil; farklı sorulara cevap veriyorlar.
- Bir gün iyi bir üst sınır. Kutsal bir sayı değil; sebep tahmin değil görünürlük: üç günlük işin “yüzde altmışı” diye bir şey yok.
- Story dikey kesilir, task da mümkün olduğunca. “API”, “veritabanı”, “ekran” diye kırmak en kolay ama en kırılgan yöntem.
- Kırılmayan iş çoğu zaman anlaşılmamış iştir. Genelde efor değil netlik problemi — ama gerçekten bölünmeyen işler de var.
Önce şu üç kelimeyi yerine oturtalım
Çoğu ekipte epic, story ve task aynı şeyin farklı boylarıymış gibi kullanılıyor: büyükse epic, ortaysa story, küçükse task. Aslında öyle değil. Üçü farklı sorulara cevap veriyor ve bunu karıştırınca backlog bir anda anlamsızlaşıyor.
| Seviye | Sorduğu soru | Kim okur | Süre |
|---|---|---|---|
| Epic | Neden yapıyoruz? | İş tarafı, yönetim | Birkaç sprint |
| Story | Kim için ne çıkıyor? | PO, ekip, QA | Bir sprint içinde biter |
| Task | Nasıl yapacağız? | Sadece ekip | En fazla bir gün |
En kritik ayrım şurada: story tek başına canlıya çıkabilir, task çıkamaz. Bir story bittiğinde dışarıda bir kullanıcı bir işini yapabiliyor olmalı. Task bittiğinde ise sadece ekip bir şey biliyor. Bu tek cümle çoğu tartışmayı bitiriyor.
Gerçek bir örnek: iade süreci
Somut olalım. Bir e-ticaret sitesinde iadeler çağrı merkezi üzerinden yürüyor. Müşteri arıyor, temsilci sistemde elle iade kaydı açıyor. Günde 400 çağrı, her biri ortalama 4 dakika. İş tarafının derdi belli: bu yükü azaltmak.
Müşteri iadeyi kendi başlatabilsin.
Hedef: iade çağrılarının %60 oranında azaltılması. Tahmini süre 2–3 sprint. Bu satır nedeni taşıyor ve altı ay sonra “bu iş niye yapılmıştı” sorusunun cevabı burada duruyor. Epic tek başına teslim edilmez, kapanır.
Şimdi bunu story’lere bölelim. Dikkat: bölerken “önce arayüzü yapalım, sonra servisi” demiyoruz. Her parça kendi başına işe yarayacak şekilde kesiliyor:
- S1 — Müşteri olarak, teslim edilmiş bir siparişim için iade talebi oluşturabilmek istiyorum; böylece çağrı merkezini aramam gerekmez.
- S2 — Müşteri olarak, iade talebimin hangi aşamada olduğunu görebilmek istiyorum; böylece durumu sormak için aramam gerekmez.
- S3 — Temsilci olarak, gelen iade taleplerini tek listede görüp onaylayabilmek istiyorum; böylece her biri için ayrı ekran gezmem gerekmez.
- S4 — Müşteri olarak, iade kargo kodumu ekranda alabilmek istiyorum; böylece kargo şubesinde beklemem gerekmez.
Dördü de tek başına canlıya çıkabilir. Sadece S1 çıksa bile bir değer var: müşteri talebi açar, arkada temsilci elle işler. Çağrı yükü daha ilk sprint’te düşmeye başlar. İşte “vertical slice” dediğimiz şey bu.
Şimdi task’lara inelim
S1’i alalım: “Müşteri iade talebi oluşturabilsin.” Çoğu ekibin yaptığı şey şu üç kartı açmak:
- Backend geliştirmesi 3 gün
- Frontend geliştirmesi 2 gün
- Test 1 gün
Üç kart, altı gün. Ve hiçbiri sprint ortasında sana bir şey söylemiyor.
- İade talebi tablosu + migration 3 sa
- POST /iade endpoint’i, happy path 5 sa
- İade uygunluk kuralı: 14 gün kontrolü 4 sa
- Uygun olmayan sipariş için hata cevabı 3 sa
- İade formu ekranı (statik) 5 sa
- Formu endpoint’e bağlama + hata gösterimi 4 sa
- Temsilciye bildirim e-postası 3 sa
İkinci liste 27 saat ediyor, ilki 48. Bu örnekte küçüldü, çünkü “backend 3 gün” tahmininin içinde ne yapılacağı tam bilinmediği için konan bir pay vardı. Her zaman böyle olmaz: kırınca gözden kaçmış alt işler de ortaya çıkar ve toplam büyür. İkisi de olur ve ikisi de iyidir; asıl kazanç süre değil, görünürlük. Test ise ayrı kart değil, her task’ın Definition of Done’ında (aşağıda). İkinci gün daily’de artık “backend’e devam” değil, “tablo ve endpoint bitti, kuraldayım” cevabını alıyorsun. Sprint’in yarısında tahtaya baktığında gerçekten nerede olduğunu görüyorsun.
8 saat kuralı: neden bir günü geçmemeli
Benim kullandığım ölçü şu: bir task tercihen bir günü geçmesin. Baştan söyleyeyim, bu bir Scrum kuralı değil — hiçbir kılavuzda geçmiyor; çalıştığım ekiplerde işe yaradığını gördüğüm bir varsayılan. Sekiz saatin de bir sihri yok: bir günü, “iki daily arasında kartın durumu değişsin” isteğinin pratik karşılığı olduğu için seçiyorum.
Sınırı bir tahmin disiplini sanmak yaygın bir yanlış. İşe yaramasının dört sebebi var ve yalnızca biri tahminle ilgili.
- İlerleme ölçülemez hale gelir. Üç günlük bir işin “yüzde altmışı” diye bir şey yoktur; o yüzde bir histir. Tek günlük task’ta iki durum vardır: bitti ya da bitmedi. His yok.
- Takılma geç fark edilir. Üç günlük task’ta insan ikinci günün sonuna kadar “hallederim” der. Tek günlük task’ta ertesi sabah bitmediyse bu herkesin gördüğü bir sinyaldir.
- Tahmin hatası büyür. Bir günlük tahminde yanılma payın saatlerle ölçülür. Beş günlük tahminde günlerle. Aynı belirsizlik, farklı fatura.
- İş devredilemez. Biri hastalanınca üç günlük yarım task’ı başkasına vermek neredeyse imkânsızdır. Bir günlük parçalarda devretme mümkün.
Bunun bir yan etkisi var, en sevdiğim kısmı da bu: bir işi bir günlük parçalara kıramamak, çoğu zaman o işin henüz anlaşılmadığını gösteriyor. Kıramama bir efor problemi gibi görünüyor; benim gördüğüm vakalarda genelde netlik problemi çıktı. O yüzden “bu kırılmıyor abi” cümlesini bir itiraz olarak değil, üzerinde bir kez daha durulacak bir sinyal olarak okuyorum: gerçekten bölünmüyor mu, yoksa henüz nasıl yapılacağı mı belli değil?
Ama her seferinde cevap aynı çıkmıyor. Bazı işler gerçekten bölünmüyor ve bunu kabul etmek, kartı zorla ikiye kesmekten iyi:
- Bilinmeyeni ölçmek. Bir spike (time-box’lı araştırma maddesi) bir günü aşabilir; onu ikiye bölmek bilgiyi artırmıyor.
- Yabancı bir kod tabanına ilk giriş. Öğrenme maliyeti bir kez ödeniyor; parçalara bölününce kaybolmuyor, sadece dağılıyor.
- Dış bir bağımlılığı beklemek. Üçüncü taraf onayı, altyapı erişimi. Kırmak süreyi kısaltmıyor; görünürlüğü de zaten bekleyiş belirliyor.
- Yarıda bırakılamayan işler. Tek seferlik veri taşıma gibi, adımları olan ama ortasında durulamayan işler.
Böyle durumlarda kartı zorlamıyorum; uzunluğun sebebini karta yazıyorum: “iki gün, çünkü X ekibinden cevap bekleniyor.” Sınırın amacı zaten kartı küçültmek değil, uzun kartın neden uzun olduğunu görünür kılmak.
Task nasıl kırılır? Altı kesme yöntemi
1. Akışa göre: önce happy path
Her şeyin yolunda gittiği senaryoyu ayrı, hata durumlarını ayrı task yap. Yukarıdaki örnekte “POST /iade happy path” ve “uygun olmayan sipariş için hata cevabı” bu şekilde ayrıldı. Happy path bitince gösterecek bir şeyin olur; hata yolları da tek tek bitirilebilir.
2. Veriye göre: önce bir tip
Beş farklı ödeme tipi mi var? İlk task sadece kredi kartı olsun. Kalanlar ayrı task’lar. Genelde ilk tip mimariyi kurar, diğerleri ikişer saat sürer. Bunu tersten yapan ekipler “hepsini birden düşünelim” deyip iki hafta soyutlama tasarlıyor.
3. Kurala göre: önce basit hal, sonra istisnalar
“14 gün içinde iade edilebilir” bir task. “Kampanyalı ürünlerde 7 gün, hijyenik ürünlerde iade yok” ayrı bir task. Kural istisnaları neredeyse her zaman tahmin edilenden uzun sürer; ana kuralla aynı karta koymak o kartı şişirir.
4. İşleme göre: önce okuma, sonra yazma
Listeleme ve görüntüleme genelde hızlıdır ve hemen değer üretir. Oluşturma, güncelleme ve silme ayrı ayrı gider. Bir CRUD ekranını tek task yapmak klasik bir üç günlük kart üretme yöntemidir.
5. Arayüz ile servisi ayır — ama dikkatli
Bunu yapabilirsin, sadece şartı var: ekranı statik veriyle bitirip gösterilebilir hale getir, sonra bağla. Böylece iki task da tek başına “bitmiş” sayılabilir. Şartı sağlamadan “önce backend, sonra frontend” diye kırarsan sprint’in son gününe kadar ortada gösterilecek hiçbir şey olmaz.
6. Bilinmeyeni ayır: araştırma ayrı bir madde
“Kargo firmasının API’si nasıl çalışıyor bilmiyoruz” bir geliştirme task’ı değildir. Ayrı bir spike olur, time-box’lıdır (örneğin 4 saat) ve çıktısı kod değil, karardır. Bunu ayırmayan ekiplerde “5 saatlik” task iki gün sürer ve kimse sebebini anlamaz; sebep koddaki zorluk değil, cevabı olmayan sorudur.
“Veritabanı”, “servis”, “ekran” diye kırmak en kolayı ve en yaygını. Sorun şu: hiçbiri tek başına çalışmaz. Üçü de bitmeden ortada gösterilecek bir şey yoktur ve entegrasyonda çıkan sürpriz — ki çıkar — sprint’in son gününe denk gelir. Katmanlı kırmak istiyorsan bari ince bir vertical slice’ı baştan sona götür: tek alanlı bir form, tek endpoint, tek kayıt.
Sık düşülen üç tuzak
| Kart | Sorun | Ne yapmalı |
|---|---|---|
| “Analiz” task’ı | Bitiş ölçütü yok, her zaman uzar | Time-box’lı bir spike yap, çıktısı bir karar olsun |
| Sona konan “Test” task’ı | Sprint sonunda QA boğulur, hata düzeltmeye vakit kalmaz | Testi Definition of Done’a göm. Ayrı kart yalnızca kendi başına bir iş yükü varsa anlamlı: regresyon otomasyonu, yük testi, dış sızma testi |
| “Refactor” task’ı | Sınırı belirsiz, üç gün sürer, kimse ne olduğunu bilmez | Dokunulacak sınıfı ve amacı adıyla yaz: “SiparisServisi’ni iki servise böl” |
Story ne zaman büyümüş sayılır?
Pratik ölçü: bir story’nin task’ları bir sprint’e sığmıyorsa o artık story değil, küçük bir epic’tir. Bölmek gerekir. Genelde bölünecek yer belli olur: “ve” kelimesinin geçtiği yer. “Müşteri iade talebi oluşturabilsin ve durumunu takip edebilsin” cümlesindeki “ve” aslında iki story olduğunu söylüyor.
Tersi de geçerli: bir task tek başına canlıya çıkıp bir kullanıcının işini görüyorsa onu task olarak tutmanın anlamı yok, story yap. Seviyeler kutsal değil; amaç doğru soruyu doğru yerde sormak.
Kontrol listesi
- Bu bir story mi? Tek başına canlıya çıksa birinin işine yarar mı?
- Task’lar en fazla bir gün mü? Değilse uzunluğun sebebi kartta yazıyor mu?
- Kartın adında ne yapılacağı yazıyor mu, yoksa “X geliştirmesi” mi?
- Bilinmeyen bir şey varsa ayrı ve time-box’lı bir spike açıldı mı?
- Ayrı bir “test” kartı var mı? Varsa kendi başına bir iş yükü mü, yoksa Definition of Done’a mı ait?
- İlk gün sonunda QA’ya verilebilecek bir task var mı?
- Story’nin metninde “ve” geçiyor mu? (Geçiyorsa muhtemelen ikiye bölünecek.)
Sonuç
İş kırmak bir Jira alışkanlığı değil, bir düşünme biçimi. Kartları küçültmenin amacı tahtayı kalabalıklaştırmak değil, her sabah gerçekte nerede olduğunu görebilmek.
Buradaki eşikler benim ekiplerimde işe yarayanlar; seninkinde bir gün yerine yarım gün ya da iki gün daha doğru gelebilir. Belirleyici olan sayının kendisi değil, o sayının sana gerçekte nerede olduğunu söyleyip söylememesi.
Ve başa dönelim: o üç gündür “devam ediyor” yazan “İade talebi oluşturma” kartı, yukarıdaki listedeki yedi ayrı task’tı. Kırılmadığı için üçü bitmiş, biri takılmış, üçüne hiç başlanmamıştı — ve bunu kimse göremiyordu. Kart bir taneydi çünkü.
Story’lerin nasıl yazılacağı ve acceptance criteria’nın nereye kadar detaylanacağı Grooming bölümünde; task’ların sprint içinde nasıl çekileceği Sprint Planning bölümünde.