refinement

Product Backlog Refinement aktivitelerinden biri de refinement etkinliğidir. Bu etkinlikte tüm takım üyeleri ve PBI’ın olgunlaşmasına katkı sağlayabilecek kişiler yer alabilir. Kısıtlı bir süre içinde birden fazla iş ele alınacağından, zamanın verimli kullanılması çok önemlidir.

Etkinlik Öncesi Hazırlık

• Önceliklerin belirlenmesi: Product Backlog’daki öncelikler, taslak da olsa belirlenmiş olmalıdır. Özellikle 1–2 sprint içinde yapılacak işlere öncelik verilmesi, zaman israfını azaltır. Gerekirse bir önceliklendirme etkinliği ile herkesin hemfikir olması sağlanabilir.

• Paydaşlarla görüşme: Product Owner, ilgili paydaşlarla ihtiyaçları netleştirmeli ve yönlendirmelidir. Her talebe “evet” denilmesi, gereksiz işlere ve israfa yol açabilir. İş değeri yüksek taleplerin öne alınması kritik önemdedir.

• Ürünler arası farkındalık: Product Owner yalnızca kendi ürünü değil, kurum içindeki diğer ürünleri de bilmeli. Böylece duplike işler önlenir, talep sahipleri doğru ürünlere yönlendirilebilir.

Etkinlik Sırasında Dikkat Edilecekler

• Olgunlaştırılacak PBI’ların önceden belirlenmesi: Etkinlik öncesinde belirlenen maddeler sayesinde zaman daha etkin kullanılır. Gereken konular için developer’lar ön hazırlık yapabilir.

• Fasilitasyon: Etkinliğin verimli geçmesi için doğru şekilde fasilite edilmesi gerekir. Bu sorumluluk Product Owner’a aittir.

• Timebox: Zaman kutulaması yapılmalıdır. Aksi halde tek bir konu tüm etkinliği doldurabilir ve diğer maddeler gözden kaçabilir.

• İncremental refinement: Sprint boyunca birden fazla refinement yapılması faydalıdır. İlk oturumda eksik kalan noktalar tespit edilip sonraki oturumlarda tamamlanabilir.

• Katılımcı çeşitliliği: Katılım sadece Scrum takımı ile sınırlı olmamalı; gerekiyorsa takım dışındaki uzmanlar da davet edilmelidir.

Etkinlik Sonrası

• Notların tutulması: Karmaşık gündemli organizasyonlarda alınan kararlar karışabilir. Bu sebeple konuşulan maddeler mutlaka kayıt altına alınmalı ve tüm takımın erişebileceği bir ortamda paylaşılmalıdır. Bu sayede:

  • Aynı konular tekrar tekrar gündeme gelmez,

  • Farklı toplantılarda farklı kararlar alınmasının önüne geçilir,

  • Herkesin aynı noktada hizalanması sağlanır.

Sonuç

Kaliteli bir planlamanın ön şartı, kaliteli refinement çalışmalarıdır. Product Owner, bu sürecin ana sorumlusu olsa da tek başına her şeyi bilmesi mümkün değildir. Bu nedenle Product Owner ve Developer’ların sürekli iletişim içinde, birlikte hareket etmesi kritik başarı faktörüdür.

Agile dönüşüm sonrası takımların en çok zorlandığı konulardan biri, Product Backlog Item (PBI)’ları Definition of Done (DoD) kriterlerini dikkate alarak küçük parçalara ayırmaktır. Buradaki amaç, her bir PBI’ın tek başına değer üretenbir iş parçası olmasıdır.

Alışkanlıklarımız genellikle işleri “analiz, yazılım, test” gibi fonksiyonel adımlara bölmek yönünde olduğundan, değer üreten parçalara bölmek ilk etapta zorluk çıkarabilir. Ancak bu kası ne kadar çok çalıştırırsak, takım o kadar hızla gelişir ve yeni yaklaşım bir alışkanlığa dönüşür.

Yazılım geliştirmedeki bir çıktının değeri, üretim ortamına deploy edilebilecek özelliklere sahip çalışan yazılım parçası olarak tanımlanabilir. Bu yüzden PBI’ları küçük parçalara bölerken “değer üretiyor mu?” sorusu en önemli kriter olmalıdır.

Takımlar PBI’ları değer odaklı küçük parçalara ayırmak için aşağıdaki yöntemlerden yararlanabilir:

1. İş Akışına Göre

Bir akışın adımlarına bölmek faydalı olabilir.
Örnek: EFT fonksiyonu için akış şu şekilde olabilir:

• Gönderen Bilgileri

• Alıcı Bilgileri

• Tutar Bilgisi

• Onay

Her adım, tamamlandığında test edilebilir, kalite onayı alınabilir ve paydaşlardan geri bildirim toplanabilir. Bu parçalar tek başına üretim ortamına alınabilir durumda olur.

2. Platform Bazlı

PBI birden fazla platformu içeriyorsa (mobil, web, desktop) her biri için ayrı PBI oluşturulabilir.
Örnek: EFT fonksiyonu → Mobil Gönderen Bilgileri, Web Gönderen Bilgileri.

3. İşletim Sistemi / Tarayıcıya Göre

Geliştirilen fonksiyon farklı tarayıcılarda veya işletim sistemlerinde çalışacaksa, her biri için ayrı PBI tanımlanabilir.

4. Parametrelere Göre

Filtreleme, arama veya veri girişi fonksiyonları parametrelere ayrılabilir.
Örnek: “Arama” fonksiyonu için isim, tarih, kategori gibi her parametre ayrı bir PBI olabilir.

5. İş Kurallarına Göre

Her akış farklı kurallar barındırabilir. Bu kurallar ayrı PBI olarak ele alınabilir.
Örnek: TC Kimlik numarasının ilk ve son 3 hanesinin maskelenmesi.

6. Test Senaryolarına Göre

Her test senaryosu bir iş kuralını ya da akışı temsil edebilir. Bu senaryolar baz alınarak PBI oluşturulabilir.

7. Rol Bazlı

Üründe farklı kullanıcı rolleri varsa, bu roller için ayrı PBI tanımlanabilir.
Örnek: Kullanıcı rolü için ayrı, yönetici rolü için ayrı geliştirmeler.

8. İşlem Türlerine Göre

İşlem tipleri farklı PBI’lara bölünebilir.
Örnek: Silme, Düzenleme, Görüntüleme gibi işlemler.

📌 Sonuç:

PBI’ları doğru şekilde küçük parçalara bölmek, hem sprint içinde değer üretimini hızlandırır hem de paydaşlardan erken geri bildirim alınmasını sağlar. Bu da ürünün pazara daha hızlı ve doğru uyumlanmasına katkıda bulunur.

Product Backlog Refinement, backlog’da yer alan işlerin olgunlaştırıldığı ve detaylandırıldığı, sürekli devam eden aktiviteler bütünüdür. Scrum Guide’ın 2013 güncellemesine kadar bu süreç Grooming olarak adlandırılıyordu. Bu nedenle araştırmalarda hem Grooming hem de Refinement ifadeleriyle karşılaşabilirsiniz.

Sorumluluklar

Product Backlog’un tek sorumlusu Product Owner’dır. Dolayısıyla backlog’un detaylandırılmasından da sorumludur. Ancak Product Owner’ın her şeyi tek başına bilmesi veya yapması mümkün değildir. Bu nedenle Developer’ların da refinement aktivitelerine katılması gerekir.

Scrum Guide, refinement’ı zorunlu etkinlikler arasında saymaz. Ancak Scrum’ın kurucuları ve sektörün önde gelen uzmanları, refinement’ın düzenli yapılmasını şiddetle tavsiye eder. Çünkü planlama etkinliklerinin kalitesi, yeterli refinement yapılıp yapılmadığının en önemli göstergesidir.

Eğer refinement sırasında hâlâ mevcut sprintteki işler detaylandırılıyorsa, bu bir önceki sprintte yeterli refinement yapılmadığının işaretidir.

Product Owner’ın Refinement Aktiviteleri

• Gelen taleplerin, maillerin ilk okunması ve ihtiyaçların netleştirilmesi

• Kendi bilgi birikimiyle backlog maddesini detaylandırmak

• Paydaşlarla görüşerek iş ihtiyacını netleştirmek

• Developer’lardan destek almak, onları paydaş toplantılarına davet etmek

• Elde edilen bilgileri refinement oturumlarında tüm developer’lar ve ilgili paydaşlarla paylaşmak

• Cevaplanamayan soruları bir sonraki refinement veya planlama öncesinde netleştirmek

Developer’ların Refinement Katkıları

• Product Owner’ın sorularını yanıtlamak

• Paydaşlarla yapılan görüşmelere katılmak

• Araştırma ve inceleme yapmak (eski doküman, kod, mimari vb.)

• Product Backlog Item’ların tahmini büyüklüklerine katkı sağlamak

Özet

Refinement, Scrum Guide’da “zorunlu etkinlik” olarak yer almasa da, Scrum’ın etkin uygulanabilmesi için kritik bir süreçtir. Düzenli yapılan refinement, daha kaliteli planlamalara, daha iyi anlaşılmış işlere ve daha verimli sprintlere doğrudan katkı sağlar.