Ana sayfa → Bölüm 03
Grooming: Ticket Okuma Seansı Değil, Vizyon Aktarımı
PO maddeyi okur, ekip başını sallar, herkes telefonuna bakar. Bu bir devir teslim değil, bir uyuşturma seansıdır. Oysa burası lansman olmalı.
- PO’nun işi “ne” değil “neden”dir. Bağlamı olmayan ekip işi sahiplenemez; sadece görev tamamlar.
- İleriyi göster. Sadece bir sonraki sprint değil, iki üç sprint ötesi de görünmeli — mimari ön düşünme ancak böyle mümkün.
- Detay uzaklaştıkça azalır. Yakın sprint piksel seviyesinde, uzak sprint ana fikir seviyesinde.
- Çözüm tasarımı burada yapılmaz. “Nasıl kodlarız” sorusu teknik analize aittir.
Refinement ile grooming aynı şey değil (bu seride)
Scrum Kılavuzu ikisini tek etkinlik sayar ve bu tartışmaya açık bir tercihtir. Pratikte ise iki farklı iş yapılıyor ve karıştırıldıklarında ikisi de kötü yapılıyor:
| Refinement | Grooming | |
|---|---|---|
| Amaç | Elemek ve önceliklendirmek | Bağlamı ekibe aktarmak |
| Konuşan | Ürün ve iş tarafı | Product Owner |
| Dinleyen | — | Geliştiriciler + QA |
| Çıktı | Filtrelenmiş, puanlanmış liste | Ekibin anladığı ve sahiplendiği maddeler |
Bu ayrımı yapmanın pratik faydası şu: refinement uzun sürerse mühendisler zaman kaybetmez, grooming uzun sürerse bu bir uyarıdır — demek ki eleme aşaması işini yapmamış.
Amaç: bağlam yüklemek
Bu aşamaya gelindiğinde PO fikirleri zaten filtrelemiş ve net gereksinimlere dönüştürmüştür. Şimdiki iş bu bağlamı ekibe aktarmak. Kritik cümle şu:
Aradaki fark küçük görünür ama sonuçları büyüktür. Bağlamı bilen bir geliştirici, gereksinimin gözden kaçmış bir köşesini kendisi fark eder ve sorar. Bağlamı bilmeyen geliştirici, yazılanı harfiyen yapar ve yanlış şeyi kusursuz teslim eder.
Somut örnek
“Sipariş ekranına bir filtre alanı ekleyeceğiz. Tarih aralığı ve durum seçilebilecek.”
“Çağrı merkezi ekibi günde ortalama 40 dakikasını sipariş ararken harcıyor. Aradıkları şeyin %80’i son 7 gün içindeki bekleyen siparişler. Bu filtreyle o süreyi yarıya indirmeyi hedefliyoruz.”
İkinci anlatımda ekip “o zaman varsayılan filtre son 7 gün + bekleyen olsun mu?” diye sorar. Bu soru birinci anlatımda hiç sorulmaz — ve özellik teslim edildikten sonra “aslında biz şunu istemiştik” olarak geri döner.
Bir sonraki sprint’in ötesi
Grooming sadece yarının görevleriyle ilgili değil. PO’nun yol haritasını gösterme fırsatı. Üç faydası var:
- Ön düşünme. İki sprint sonra geleceğini bilen bir geliştirici, bugünkü tasarımı ona göre kurgular. Bunu söylemeseniz de yapar — insan beyni arka planda çalışır.
- Motivasyon. Ekip yaptığı işin daha büyük bir resme hizmet ettiğini görür. Yol haritası görmeyen ekip, kendini bir görev kuyruğu tüketicisi gibi hisseder.
- Erken itiraz. “O özelliği yapacaksak bugünkü tabloyu böyle kurmayalım” itirazı, iki sprint sonra gelirse pahalıdır; bugün gelirse bedavadır.
- Bir sonraki sprint: kabul kriterleri, ekran taslakları, uç durumlar — piksel seviyesi.
- +2 sprint: ana akış ve iş kuralları, ekran yok.
- +3 ve sonrası: tek cümlelik başlık. Sadece “bu geliyor” bilgisi.
Oturumun akışı
- Hikâye. PO kullanıcı hikâyesini, iş ihtiyacını ve kabul kriterlerini anlatır.
- Bağlam. Neden şimdi, kimin için, hangi ölçüyü değiştirecek?
- Sorular. Ekip açıklayıcı sorular sorar: “kullanıcı geri tuşuna basarsa?”, “mobilde nasıl görünecek?”, “yetkisiz kullanıcı ne görecek?”
- Karar. Madde hazır mı, yoksa PO’ya geri mi dönüyor?
PO fonksiyonel bir soruyu cevaplayamıyorsa madde hazır değildir. “Sonra bakarız” diyerek maddeyi sprint’e almak, belirsizliği en pahalı yere — geliştirme aşamasına — taşımaktır. Ekip belirsizliği kabul etmez; madde geri döner.
Kendi eklediğim kural: oturumda cevaplanamayan her sorunun yanına kimin cevaplayacağı ve ne zamana kadar cevaplayacağı yazılır. Bu iki bilgi olmadan “PO bakacak” notu, sprint planning’de aynı sorunun tekrar sorulmasıyla sonuçlanır. Retrospektif bölümündeki aksiyon kuralının aynısı burada da geçerli.
Anti-pattern’ler
- Ticket okuma: PO ekrandaki metni sesli okur, kimse konuşmaz.
- Çözüm kayması: Oturum “hangi tabloya yazalım” tartışmasına döner.
- Tek yönlü: Soru sorulmaz. Soru sorulmayan grooming, anlaşılmamış demektir.
- Hazır olmayan maddeyi geçirmek: “Detayı sprint içinde netleştiririz.”
- Her maddede “bu kimin hangi derdini çözüyor” cümlesini zorunlu tut
- Çözüm tartışması başlayınca durdur, teknik analize park et
- Her maddeden sonra “sorusu olan?” diye bekle — sessizliği onay sayma
- Hazır olmayan maddeyi geri gönder, bunu bir başarı say
Kontrol listesi
- Her maddenin kabul kriterleri yazılı mı?
- Her madde için ekipten en az bir soru geldi mi?
- Cevaplanamayan sorulara sorumlu ve tarih atandı mı?
- İki üç sprint ilerisi ana hatlarıyla gösterildi mi?
- “Nasıl yapacağız” tartışması teknik analize park edildi mi?
- Hazır olmayan maddeler geri gönderildi mi?
Sonuç
Grooming, iş dilinin ürün gereksinimine çevrildiği yerdir. Doğru yapıldığında oturum şu cümleyle biter: “Tamam, neye ihtiyacın olduğunu anladık. Şimdi bunu nasıl yapacağımızı çözmemize izin ver.”
Bu cümle söylenmiyorsa ya bağlam aktarılmamıştır ya da ekip sormaktan vazgeçmiştir. İkisi de aynı yere çıkar: sprint ortasında sorulacak sorular.
Bağlam aktarımı, azalan granülarite ve altın kural, İbrahim Demir’in Grooming yazısından uyarlandı. Refinement/grooming ayrım tablosu, bağlamlı-bağlamsız örneği ve “cevapsız soruya sorumlu + tarih” kuralı benim eklemem. Mike Cohn’un User Stories Applied kitabı bu konuda temel referans.