Ana sayfa → Bölüm 02
Backlog Refinement: Kötü Fikri Erken Öldürmek
Refinement bir tören değil, bir huni. Ve bu huni toplantı odasında değil, bir fikir ilk doğduğu anda başlar.
- Önce ele, sonra detaylandır. Zayıf fikri bir zarfın arkasına sığacak hesapla, iki dakikada öldür.
- Bu ürünün işi. Mühendisleri filtreleme oturumuna çekmek toplantı yorgunluğu üretir; onlara sadece olgunlaşmış madde ulaşmalı.
- Ortak para birimi şart. Yasal, ciro ve maliyet düşürücü işler ancak kâr ekseninde eşitlenirse karşılaştırılabilir.
- ROI eşitse küçük olanı seç. Erken çıkış hem geliri öne çeker hem de asıl riski — müşterinin tepkisini — erken öğretir.
Seremoni tiyatrosu problemi
Çoğu ekipte refinement, tahtadaki maddelerin sırayla okunduğu bir saatlik oturumdur. Herkes katılır, kimse konuşmaz, sonunda hiçbir madde elenmez. Bu bir arıtma değil, bir okuma seansıdır.
Refinement’in asıl işi maddeleri güzelleştirmek değil, çoğunu elemektir. Huninin ağzından giren yüz fikirden ekibe on tanesi ulaşmalıdır. Eleme yapılmıyorsa huni değil, boru vardır.
Filtreleme aşamasında geliştiriciler ve QA bulunmaz. Refinement bir ürün ve iş yönetimi alanıdır. Mühendislik ekibini buraya çekmenin tek sonucu, kod yazacak saatlerin toplantıda geçmesidir.
Kendi eklediğim istisna: bir fikrin değeri tamamen teknik fizibiliteye bağlıysa (“bu entegrasyon mümkün mü?”), tek bir mühendisten tek bir madde için on dakikalık görüş al. Oturumun tamamına davet etme. Fark şu: mühendis katılımcı değil, danışılan kişi.
1. İlk filtre: zarfın arkası hesabı
Bir fikrin mantıklı olup olmadığını anlamak için detaylı rapora ihtiyacın yok. Bir zarfın arkasına sığacak, bir iki dakikada yapılabilecek kaba bir hesap yeterli: kaç kullanıcı, ne sıklıkla, ne kadar kazanç ya da tasarruf?
Bu hesap “potansiyel var” demiyorsa o fikre tek dakika daha harcama. Burada elenmeyen her çöp fikir, ileride analiz, tasarım ve geliştirme aşamalarında katlanarak büyüyen bir maliyete dönüşür.
2. ROI matematiği: elmayı elmayla karşılaştırmak
Fikir ilk filtreyi geçtiyse artık diğerleriyle kıyaslanmalı. Sorun şu ki işlerin getirisi aynı dili konuşmaz. Kabaca üç kategori var:
- Yasal / zorunlu: yapılmazsa ceza, kesinti veya risk doğurur.
- Ciro (revenue): kasaya para sokar.
- Maliyet düşürücü (cost down): cepten para çıkmasını engeller.
Yasal ve maliyet düşürücü işler doğrudan kâra yazılır. Ciro işlerinde ise her lira kâr değildir. Karşılaştırmanın dürüst olabilmesi için hepsini kâr eksenine taşımak gerekir.
Brüt kâr marjın %20 ise, 100 TL tasarruf etmek 500 TL ciro yapmaya denktir (100 ÷ 0,20 = 500). Yani maliyet düşürücü ve yasal işleri ciro işleriyle kıyaslarken 5 ile çarpman gerekir.
Bu çarpanı bir kez hesaplayıp herkesin görebileceği bir yere yaz. Çoğu önceliklendirme tartışması aslında bu çarpanın konuşulmamış olmasından çıkıyor.
3. Efor: T-shirt boyutlandırma
Bu aşamada saat bazlı tahmin yapmaya çalışmak zaman kaybıdır; elde henüz teknik analiz yok. Kaba bir boyut yeterli. Önemli olan ölçeğin doğrusal değil üssel olması: iş büyüdükçe artan şey sadece süre değil, belirsizliktir.
| Boyut | Yaklaşık süre | Puan |
|---|---|---|
| XS | 1 sprint | 1 |
| S | 2 sprint | 2 |
| M | 4 sprint | 4 |
| L | 8 sprint | 8 |
| XL | 16 sprint | 16 |
| 2XL | 32 sprint | 32 |
Kendi kuralım: L ve üstü bir madde backlog’a olduğu gibi girmemeli. XL bir madde bir iş değil, bir temennidir. Parçalanamıyorsa bu, henüz yeterince anlaşılmadığının işaretidir — ve anlaşılmayan iş tahmin edilemez.
4. ROI ve pazara çıkış süresi
Elinde normalize edilmiş bir etki ve puanlanmış bir efor var. Denklem basit:
ROI = Etki (kâr ekseninde) / Efor (t-shirt puanı)Kritik strateji burada: iki işin ROI’si birbirine yakınsa her zaman eforu küçük olanı seç. Sebebi sadece hız değil. Küçük iş daha erken canlıya çıkar, geliri daha erken üretmeye başlar ve en önemlisi, asıl riski — müşterinin gerçekte ne yapacağını — daha erken öğretir.
Büyük işin ROI’si tahmini bir sayıdır; küçük işin sonucu ise iki hafta sonra elindeki veridir. Tahmin ile veri arasında seçim yapıyorsan veriyi seç.
5. Süreç seni yavaşlatıyorsa o artık Agile değil
Bazı ekipler önceliklendirmeyi bile bürokrasiye dönüştürür: her fikir için formlar, onay basamakları, puanlama komiteleri. Sonunda ortaya çıkan şey daha iyi kararlar değil, daha yavaş kararlar olur.
Aşırı mühendislik tuzağı şu şekilde tanınır: her şeyi kitaba göre yapıyorsun ama müşteriye değer üretmiyorsun. Bu durumda süreç değil, süreç tiyatrosu işletiyorsundur.
- Her fikri, doğduğu anda kaba bir hesapla test et
- Kâr marjı çarpanını bir kez hesapla, herkese açık tut
- ROI’si yakın işlerde küçük olanı seç
- Elenen fikirleri sil değil, “elendi + gerekçe” olarak sakla
- Bütün ekibi filtreleme oturumuna doldurmak
- Teknik analiz yokken saat bazlı tahmin istemek
- Ciro ile tasarrufu aynı sayı gibi karşılaştırmak
- Hiç madde elemeden toplantıyı bitirmek
Kontrol listesi
- Bu oturumda en az bir madde elendi mi?
- Kalan her maddenin kaba bir etki sayısı ve t-shirt boyutu var mı?
- Etki sayıları aynı eksende mi (kâr), yoksa elma ile armut mu karşılaştırıldı?
- L ve üstü maddeler parçalandı mı, yoksa öylece mi bırakıldı?
- Elenen maddelerin gerekçesi yazıldı mı? (Aynı fikir üç ay sonra geri gelecek.)
- Bir sonraki grooming’e girecek maddeler net mi?
Sonuç
Refinement kaosu bitirmez; kaosu huninin dışında tutar. Bir işin kaba hesabı tutmuyorsa, o iş için harcanan her saat israftır — ve bu israf en pahalı yerde, geliştirme aşamasında ortaya çıkar.
Sıradaki bölümde huniden geçen maddelerin ekibe nasıl aktarıldığına bakacağız. Çünkü doğru işi seçmek yetmiyor; ekibin onu neden yaptığını bilmesi gerekiyor.
Bu bölümdeki huni yaklaşımı ve zarfın arkası hesabı, İbrahim Demir’in Backlog Refinement yazısından ilham alıyor; T-shirt ölçeği ve ROI çarpanı oradan uyarlandı. L/XL kuralı ve elenen maddelerin gerekçesiyle saklanması benim eklemem. Ayrıca Melissa Perri’nin Escaping the Build Trap kitabı bu konuda iyi bir devam okuması.