Mobil Geliştirmede Görev Grooming'i: Nedir, Amaçları ve Uygulama Süreci

Görev Grooming'i Nedir?

Backlog Grooming (düzenleme), gelecek sprint'ler için Product Backlog öğelerini hazırlama sürecidir. Product Owner ve geliştirme takımının görevleri incelediği bir toplantıdır: gereksinimleri netleştirir, Acceptance Criteria ekler, karmaşıklığı tahmin eder, bağımlılıkları ve riskleri belirler. Scrum Guide'da “Grooming” adlı zorunlu bir etkinlik yoktur — bu, Scrum takımlarının Sprint Planning'deki belirsizliği azaltmak için benimsediği ek bir uygulamadır. Önerilen sıklık, sprint başına bir kez, en fazla 60 dakikadır.

“Grooming” terimi özü yansıtır: takım backlog'u “tımar eder”, eski görevleri kaldırır, belirsiz olanları netleştirir ve çok büyük olanları böler. Mobil geliştirmede, platform özellikleri nedeniyle grooming özellikle önemlidir: Bir Android görevi, iOS sürümünden karmaşıklık açısından farklılık gösterebilir ve targetSdk, compileSdk ile API seviyeleriyle uyumluluk dikkate alınmalıdır. Grooming olmadan, Sprint Planning kaosa dönüşür — takım görevleri ilk kez görür ve tahmin edemez, bu da öngörülemezliğe ve teslim tarihlerinin kaçırılmasına yol açar.

Grooming'in sonucu, Sprint Planning için hazır bir dizi görevdir: açıklamaları, Acceptance Criteria'ları ve tahminleri vardır ve Definition of Ready'yi karşılarlar. Product Owner, görevleri öncelik sırasına göre düzenlemelidir: mevcut sprint'e en yakın olanlar en ayrıntılı olmalıdır. 3–4 sprint ötedeki görevler yalnızca epik düzeyinde kalmalıdır. Progressive Refinement tekniği: bir görev sprint'e ne kadar yakınsa, açıklaması o kadar ayrıntılı olur. Mevcut sprint görevleri için — tam düzenleme (AC, tasarım, API şartnamesi). 2 sprint ötedeki görevler için — hikaye düzeyi (uygulama detayları olmayan kullanıcı hikayesi). 3+ sprint ötedeki görevler için — epik düzeyi (yalnızca ad ve iş değeri).

Definition of Ready: Bir Görev Sprint'e Ne Zaman Hazırdır

Definition of Ready (DoR), bir görevin Sprint Backlog'a dahil edilmeden önce karşılaması gereken kriterlerin kontrol listesidir. DoR, Product Owner ile takım arasındaki bir sözleşmedir: PO, geliştirme için gerekli tüm bilgilerin mevcut olduğunu garanti eder ve takım, görevi tahmin edip tamamlayabileceğini garanti eder. DoR evrensel değildir — her takım kendi kriter setini belirler. DoR olmadan, bir görev belirsiz gereksinimlerle sprint'e girebilir ve bu da yeniden çalışmaya ve teslim tarihlerinin kaçırılmasına yol açar.

Mobil geliştirme için tipik DoR: 1) Acceptance Criteria açıklanmıştır (Given-When-Then formatında). 2) UI görevleri için Figma'da tasarım mokapı hazırdır (tüm durumlarla: default, loading, error, empty state). 3) API şartnamesi onaylanmıştır (OpenAPI/Swagger, istek ve yanıt örnekleri). 4) Story point cinsinden tahmin mevcuttur. 5) Diğer görevlere bağımlılıklar belirlenmiştir. 6) Görev, tamamlanmamış harici bileşenlere bağlı değildir. 7) Mobil özellikler: hedef OS sürümleri tanımlanmış, feature flag gerekliliği, eski API seviyeleri desteği.

Görev Tahmin Teknikleri

Planning Poker, grooming'de en popüler tahmin tekniğidir. Her geliştirici, Fibonacci sayılarını (1, 2, 3, 5, 8, 13, 21) içeren bir kart destesi alır. PO bir görevi sunar ve açıklar. Tartışmanın ardından herkes aynı anda kartını gösterir. Tahminler önemli ölçüde farklılık gösterirse (örneğin 3 ve 13), geliştiriciler gerekçelerini açıklar ve tekrar oy kullanır. Tekrarlar, fikir birliğine varılana kadar devam eder. Planning Poker'in amacı kesin tahmin değil, görev anlayışındaki farklılıkları ortaya çıkarmaktır.

T-Shirt Sizing, hızlı tahmin için basitleştirilmiş bir tekniktir: XS (1 SP), S (2), M (3), L (5), XL (8), XXL (13). Çok sayıda görev olduğunda ve kabaca bir büyüklük sırasına ihtiyaç duyulduğunda ilk backlog sınıflandırması için uygundur. T-Shirt Sizing'den sonra, bir sonraki sprint'in görevleri için Planning Poker aracılığıyla daha kesin bir tahmin yapılır. Affinity Estimation, görevlerin sayı kullanılmadan en basitten en karmaşığa doğru bir masaya dizildiği, ardından kümelere ayrıldığı ve her kümenin bir tahmin aldığı bir grup sıralama tekniğidir.

Mobil geliştirmede tahmin, platform karmaşıklığını hesaba katmalıdır. Bir Android görevi 5 SP olarak tahmin edilirken aynı görev iOS için 3 SP olabilir (veya tam tersi). Bu normaldir: farklı platformların uygulama karmaşıklığı farklıdır. İpucu: takım cross-platform ise her platformu ayrı ayrı tahmin edin. Göreceli bir ölçek kullanın: temel bir görev (örneğin metin ve düğme içeren bir ekran) = 1 SP. Diğer her şey buna görecelidir. Scrum.org (2025)'e göre, 3–4 sprint sonrası takımın tahmin doğruluğu gerçek karmaşıklığın ±%20'sine ulaşır.

Parçalama: Büyük Görevler Nasıl Bölünür

8 SP'den büyük görevler daha küçük görevlere bölünmelidir. Büyük görevler tek bir sprint'te tamamlanamaz, tahmin edilmesi zordur ve ilerleme hissi vermez. Parçalama teknikleri: görevi yatay katmanlara (UI → ViewModel → Repository → Network/DB) veya dikey dilimlere (özellik: tek bir tam ekran) bölün. Yatay parçalama mobil geliştirme için daha uygundur: Alt görev 1 — UI düzeni (XML/Jetpack Compose/SwiftUI), Alt görev 2 — ViewModel + State, Alt görev 3 — Repository + Network, Alt görev 4 — Birim testleri.

Dikey parçalama — kullanıcı hikayelerini bağımsız değere sahip daha küçük hikayelere bölme. Örnek: Epik “Alışveriş Sepeti” → Hikaye 1 “Sepete ürün ekleme”, Hikaye 2 “Sepeti görüntüleme”, Hikaye 3 “Sepetten ürün çıkarma”, Hikaye 4 “Ödeme”. Her hikayenin kendi iş değeri vardır ve bağımsız olarak yayınlanabilir. SPoK (Kano'ya Göre Story Point'ler): hikayeleri iş değerine göre sıralayın (Must-have, Should-have, Could-have) ve değer sırasına göre uygulayın.

Grooming'de parçalama kontrol listesi: 1) Görev 8 SP'den büyük mü? → Parçalayın. 2) Acceptance Criteria tanımlanmış mı? → Değilse ekleyin. 3) Diğer görevlere bağlı mı? → Bağımlılıkları belirleyin ve belgeleyin. 4) Belirsizlik içeriyor mu? → Ana görevden önce bir Spike (araştırma) ekleyin. 5) Tasarım gerekiyor mu? → Mokapların hazır olup olmadığını kontrol edin. INVEST kuralı: Independent (diğerlerinden bağımsız), Negotiable (pazarlık edilebilir), Valuable (iş için değerli), Estimable (tahmin edilebilir), Small (küçük), Testable (test edilebilir). Bir görev INVEST'u karşılamıyorsa sprint için hazır değildir.

Grooming Süreci: Adım Adım

Adım 1: Isınma (5 dakika). Scrum Master takıma grooming'in amacını ve DoR'u hatırlatır. Takım panoya bakar ve PO hangi görevlerin tartışılacağını gösterir. Adım 2: Görev İncelemesi (30 dakika). PO, mevcut sprint'in sonundan bir sonrakinin başına kadar görevleri sırayla sunar. Her görev için: ad, açıklama, Acceptance Criteria (varsa), tasarım bağlantısı, API şartnamesi. Takım açıklayıcı sorular sorar: “Boş durum için mokap var mı?”, “Hangi HTTP yöntemi?”, “iOS minimum deployment target nedir?”

Adım 3: Tahmin (15 dakika). Takım, Planning Poker veya T-Shirt Sizing ile görevi tahmin eder. Fark 2 SP'den fazlaysa nedenleri tartışır ve tekrar oy kullanır. Kural: bir görev tahmin edilemiyorsa (gereksinimler belirsiz, tasarım yok) — PO'ya düzeltme için geri gönderilir ve açıklamalarla birlikte bir sonraki grooming'e gelir. Bilinmeyenleri olan görevleri tahmin etmeyin — bu sprint'te hatalara yol açar. Adım 4: Sonuçları Kaydetme (10 dakika). PO, Jira/Linear'da tahminleri kaydeder, görev açıklamasını günceller ve öncelikleri belirler.

Grooming sonuçları: Sprint Planning için tamamen hazır 3–7 görev (DoR, tahmin, tasarım, API ile). PO backlog'u günceller: eski görevleri kaldırır, kopyaları birleştirir ve öncelikleri netleştirir. Önemli: grooming PO'nun işini bitirmez — grooming oturumları arasında PO, sonraki görevleri hazırlamalıdır. Önerilen tempo: PO, grooming için 3–4 görev hazırlar ve takım bunları işler. Backlog'da 50'den fazla görev varsa, PO grooming'den önce önceliklendirme (MoSCoW veya Weighted Shortest Job First) yapmalıdır.

Grooming ve Sprint Planning Arasındaki Farklar

Grooming hazırlıktır. Taahhüt yoktur — görev sadece netleştirilir ve tahmin edilir. Sprint Planning bir taahhüttür. Takım, grooming'de hazırlanan görevler arasından seçim yapar ve bunları sprint içinde tamamlamayı taahhüt eder. Temel farklar: grooming belirli bir sprint'e bağlı değildir (genel olarak backlog düzenlemesi), grooming sırasında Sprint Goal yoktur ve grooming sprint içinde herhangi bir zamanda yapılabilir. Sprint Planning kesinlikle sprint başında yapılır ve her zaman bir Sprint Goal ile sonuçlanır.

Grooming'de görevler sadece tahmin edilir, ancak sprint'e alınmaz. Planning'de görevler hazırlanan havuzdan seçilir. Grooming olmadan Sprint Planning 6–8 saat sürer (4 yerine), çünkü takım görevleri ilk kez görür ve hızlıca tahmin edemez. 80/20 kuralı: Sprint Planning'deki görevlerin %80'i tamamen hazır olmalıdır (grooming'den geçmiş), %20'si yeni olabilir (acil hatalar, hotfix'ler). Planning'de görevlerin %20'sinden fazlası tahmin edilmemişse grooming yetersizdi.

Yaygın Grooming Hataları

Hata 1: ayda bir grooming. Takım 3–4 sprint'lik görev biriktirir ve her şeyi 2 saatte düzenlemeye çalışır. Sonuç: görevlerin yarısı tahmin edilmemiş kalır ve Planning tüm gün sürer. Çözüm: grooming düzenli olmalıdır — sprint başına bir kez, 60 dakika. Çok fazla görev varsa sprint ortasında ikinci bir grooming ekleyin. Az sayıda görevi derinlemesine düzenlemek, çok sayıda görevi yüzeysel düzenlemekten daha iyidir. Tempo: grooming oturumu başına 3–5 görev, her biri tam tartışma ve tahmin alır.

Hata 2: bağlamsız tahmin. PO, tasarım, API veya AC olmadan “Alışveriş sepeti ekranını uygula” görevini sunar. Takım “göz kararı” 13 SP olarak tahmin eder. Planning'de aslında 5 SP olduğu ortaya çıkar (çünkü ekran basittir). Çözüm: tasarım veya API yoksa görev tahmin edilmez. PO, grooming'den önce malzemeleri hazırlamalıdır. Kural: “Mokap yok — tahmin yok”. İstisna: Spike görevler — belirsizlik araştırması, tasarım olmadan ayrı ayrı tahmin edilir (araştırma karmaşıklığına bağlı olarak 2–5 SP).

Hata 3: grooming'in Planning'e dönüşmesi. Takım, görevleri kişilere atamaya ve kimin ne yapacağını tartışmaya başlar. Çözüm: grooming'in netleştirme için olduğunu, atama için olmadığını hatırlatın. Atama — sprint başladıktan sonra Daily'de yapılır. Grooming “ne yapılmalı?” sorusunu, Planning “ne zaman yapılmalı?” sorusunu, Daily “kim yapıyor?” sorusunu yanıtlar. Bu soruları tek bir toplantıda karıştırmak her birinin etkinliğini azaltır. Scrum Master, Planning benzeri tartışmaları durdurmalı ve odağı görev netleştirmeye yönlendirmelidir.

Hata 4: Teknik Borcu görmezden gelmek. Grooming'de sadece yeni özellikler tartışılır, teknik görevler görmezden gelinir. 3–4 sprint sonra teknik borç kritik seviyeye ulaşır. Çözüm: her grooming'de en az 1 teknik görev tahmin edilmelidir. Oran: her 3 özellik için → 1 teknik görev. Tech Debt Ratio metriğini kullanın: bir sprint'teki teknik görevlerin özellik görevlerine oranı. Hedef değer: 0.25–0.3 (teknik borç için zamanın %25–30'u). Oran 0.2'nin altındaysa sonraki sprint'lerde geliştirme hızı düşecektir.