Product Backlog Refinement (Grooming)
En yaygın çevik yazılım prensiplerinden bir tanesi de product backlog refinement (bekleyen işleri iyileştirme) veya grooming (tımar) da denilen oturumlardır.
Diğer oturumlarda olduğu gibi grooming de çok sayıda kişinin katılımı ile gerçekleştirilir. Böylece sprint planlama oturumları çok daha iyi çalışılmış bir liste üzerinden gidilerek yapılır, ekip bekleyen işlere çok daha hakim olur.
Grooming oturumlarına tüm takımın katılması şart değildir. Birincil amaç;
- backlogda bekleyen işleri önceliklendirmek
- bekleyen işleri daha iyi anlamak ve onları geliştirmek
bu amacı sağlamaya doğrudan faydası olacak kişilerin katımı yeterlidir. Bu oturum, genellikle bir sprint bitiminden iki ila üç gün önce gerçekleşir.
Şimdi, backlog’daki işleri önceliklendirmede kullanılan yöntemlere göz atalım.
Backlog Önceliklendirme Teknikleri
MoSCoW Method
Önceliklendirme yöntemleri arasındaki kolay ve subjektif olanlarından birisidir. Ekibin tecrübesine güvenerek, hangi işlerin olmazsa olmaz (M), hangi işlerin gerekli (S), hangilerinin yapılsa iyi olur (C), hangilerinin yapılmaması lazım (W) olduğu belirlenir.
- M (olmazsa olmaz/must have): Bu özellikler, nihai çözümde yerine getirilmeli ve tartışılamaz olmalıdır. Ürün onlarsız başarısız olur.
- S (olmalı/should have): Bu özelliklerin hemen şimdi başlatılması kritik değildir, ancak yüksek önceliğe sahiptir. Öncelik listesinde 2. sırada yer alırlar.
- C (olabilir/could have): Yapılması istenen ancak zorunlu olmayan koşullar. Bunlar genellikle ürün için düşük maliyetli geliştirmelerdir. Hızlı ama faydalı sonuç getirirler.
- W (olmamalı/won’t have): Bunlar en az kritik olanlardır. Genellikle mevcut sürümde kullanılmaz ancak gelecekteki sürümler için revize edilebilir.
Bir sonraki sprint planlanırken işlerin çoğunluğu M olanlardan (%60), %40'ı da S ve C işlerden seçilebilir.
Kano Model
Kano modeli, 1980'lerde Profesör Noriaki Kano tarafından geliştirilen, işlerin müşterilerin ihtiyaç ve beklentilerine göre kategorize edildiği bir yöntemdir.
Kano modelinin çeşitli versiyonları vardır. Ancak orijinalinde öğeler beş başlık altında sınıflandırır: Must Be (Olması Gereken), Attractive (Çekici), One Dimensional (Tek Boyutlu), (Indifferent) Kayıtsız ve (Reverse) Ters.
Must Be (Olması Gerekenler): Bunlar müşterileriniz tarafından beklenen ama tamamlandığında woooow dedirtmeyen özelliklerdir. Ürününüze dahil edilmelidirler ve genellikle hafife alınırlar.
Attractive (Çekici): Bunlar yapıldığında kullanıcıları mutlu eder, ancak olmadıklarında onları hayal kırıklığına da uğratmaz.
One Dimensional (Tek Boyutlu): Bunlar, kullanıcıları orada olduklarında mutlu eden, olmadıklarında mutsuz eden özelliklerdir.
Indifferent (Kayıtsız): Bunların müşteri memnuniyeti seviyeleri üzerinde hiçbir etkisi yoktur. Örneğin, okunması ve anlaşılması daha kolay olacak şekilde refactoring yapılması, TDD uygulamanız vs… Müşteri için doğrudan bir değer yok gibi görünür, ancak işi gelecekte daha iyi sürdürmenizi sağlar.
Reverse (Ters): Bunlar, kullanıcıları orada olduklarında mutsuz, olmadıklarında mutlu eder. Örneğin, oturum açmak için fazladan bir adım gerektiren yüksek güvenlikli özellikler uygulayabilirsiniz. Bununla birlikte, müşteriler gelişmiş güvenliğe değer vermezlerse, ekstra adımdan memnun kalmayacaklardır.
Aynen MoSCoW metodundaki gibi, sıradaki sprintinizi planlarken bu kategorilerden dengeli bir oran belirleyip yola koyulabilirsiniz.
Kano metodu hakkında daha ayrıntılı bilgiye şuradan ulaşabilirsiniz:
Affinity (Yakınlık) Analizi
Bir proje yeni başlamışsa ve henüz tahmin edilmemiş çok sayıda iş varsa, hızlı bir şekilde işleri sıraya sokmakta kullanılan bir tekniktir.
Örnek vermek gerekirse, planlama pokeri yazısında bahsi geçen T-shirt bedeni yöntemi bir affinity analizi yöntemidir.
Bu yöntemle, tüm işleri ekipçe belirlediğiniz kategorilere göre hızlıca tartışır ve sınıflandırırsınız. Bu sınıflar: Önemli, Çok önemli, Önemsiz gibi olabilir. Veya t-shirt bedenleri, gezegen isimleri vs… aklınıza ne geliyorsa kullanılabilir.
Cost of Delay (Gecikmenin Bedeli) Yöntemi
Gecikmenin maliyetini ölçmek için şu basit soruya yanıt ararız:
Teslimi geciktirirsek bunun bize maliyeti ne olur?
Ardından, işleri “gecikirse bize en yüksek maliyeti olacak” ve “en ucuz” olanları ilk yapacak şekilde sıralarız. Bu sıralama yöntemine Weighted Shortest Job First (WSJF) prioritization (ağırlıklı en kısa işi önceliklendirme yöntemi) de denilir.
Gecikme maliyetinin mutlaka para birimi cinsinden ölçülmediğini unutmayın. Değer ve maliyeti değerlendirmenin birçok yolu vardır. Zaman, itibar veya story point kullanılan yöntemlerdendir. Rasyonel ve ölçülebilir olması açısından ben story point kullanılmasını öneriyorum.
Bu konuda daha detaylı bilgiye şu adresten ulaşabilirsiniz.
Grooming oturumları, ekibi bir sonraki sprinte hazırlamak ve ürün sahibinin backlog’una hakim olmasını, detaylarını ve öncelikleri anlamak için çok önemli bir fırsattır.
Her sprintte kabaca 1–1.5 saatinizi ayırarak bu oturumu tekrarlamanızı öneriyorum.
