Sprint Planning Doğru Yapılırsa: Tahmin, Taahhüt ve Ekiplerin Tekrarladığı Hatalar

Sprint Planning’i final sınavı olarak düşünmeyi severim. Ama bu kitapların açık olduğu bir sınavdır ve cevaplar Arıtma (Refinement) sırasında yazılmıştır. Eğer Planlama’da yeni gereksinimler keşfediyorsanız, çoktan kaldınız demektir. Burası beyin fırtılası zamanı değildir. Burası taahhüt zamanıdır. Takım dümene geçer, kapsamı kilitler ve “Bizde,” der.

Agile Serisi — Kopya Kağıdı’nın 5. Bölümü.

Rol Değişimi

Grooming’de PO konuştu ve takım dinledi. Teknik Analiz’de, takım kendi arasında konuştu. Şimdi, Planlama’da, Takım konuşur ve PO dinler.

• Klavye Takımdadır.
• Takım planı açıklar: “X Hikayesi için, bu API’yi oluşturacağız, şu DB tablosunu değiştireceğiz ve bu kütüphaneyi kullanacağız.” (Geri-Okuma / Read-Back). INVEST kriterlerine uygun yazılmış hikayeler bu açıklamayı netleştirir ve uzlaşıyı hızlandırır.
• Ürün Sahibi doğrular: “Evet, bu iş ihtiyacını karşılıyor gibi görünüyor.”

Poker Oyunu (Son Tahmin)

Çünkü takım Teknik Analiz’de işi zaten parçalarına ayırmıştır:

1. Tahminleme hızlıdır. Herkes karmaşıklığı bilir.
2. Konsensüs kolaydır. Artık “nasıl”ı tartışmayız.
3. Düşük Risk. “Bilinmeyenler” önceki fazda öldürülmüştür (veya madde reddedilmiştir).

Strateji: Önceliklendirme ve Akış

Planlama sadece “ne” yapılacağıyla ilgili değildir, akışın “nasıl” yürütüleceğiyle de ilgilidir.

1. Sıkı Önceliklendirme: Proje aracında (örn. Jira), her görev önceliğe göre sıralanmalıdır.

2. Çekme Sistemi (Pull System): Başlangıçta her işe (ticket) bir sahip atamayız.

   • Üyeler sadece ilk görevlerini üzerine alır.
   • Gerisi Sprint Backlog’da sahipsiz kalır.
   • Bir üye bir görevi bitirdiğinde, onu günceller ve kendi alanındaki bir sonraki en yüksek öncelikli maddeyi çeker.

3. QA’e Hızlı Geçiş: Hedef, ilk test edilebilir maddeyi QA’e mümkün olduğunca hızlı (ideal olarak 1. Günün sonunda) teslim etmektir.

   • QA için 1. Gün: Yazılımcılar kodlamaya başlarken, QA test veri setlerini ve ortamları hazırlar.

Bilgi Transferi: Eş Programlama (Pair Programming)

Siloları yıkmak için sprint’i açıkça kullanırız. Planlama sırasında, Eş Programlama’ya uygun görevleri belirleriz.

• Neden Pair?
  1. Teknik Transfer: “Bu temiz kodu nasıl yazarız?”
  2. İş Transferi: “Bu eski (legacy) hesaplama neden böyle çalışıyor?” (Alan uzmanı uygulayıcıyı yönlendirir).
• İş Başında Eğitim: Bilmediğim bir görevi seçersem, plana bakarım ve görürüm: “Ah, bunun için Kişi X ile eşleşmem lazım.”
• Yatırım: Toplam sprint eforunun %20-40’ını eşleşmeye ayırmayı öneririm. Bu siloları önler ve sonunda takım hızını (velocity) önemli ölçüde artırır.

Taahhüt (The Commitment)

Bu bir pazarlık değildir. Takım kapasitesine bakar ve teslim edebileceğini bildiği işi çeker. Teknik riskler çözüldüğü için, taahhüt bir “tahmin”den çok daha güçlüdür.