Sprint Planning: Tahmin Değil Taahhüt

Rol değişimi: klavye artık ekipte

Grooming’de yön PO’dan ekibe doğruydu. Planning’de bu yön tersine döner ve bu tersine dönüş, toplantının tamamını belirler.

• Ekip planı anlatır: “Bu hikâye için şu endpoint’i açacağız, şu tabloya alan ekleyeceğiz, migration şu sırayla gidecek.” Buna geri okuma denir.
• PO doğrular: “Evet, bu anlattığın şey benim ihtiyacımı karşılıyor.”

Geri okumanın değeri şurada: PO’nun kafasındaki çözümle ekibin kafasındaki çözüm farklıysa bu fark burada ortaya çıkar. Ortaya çıkmazsa sprint’in sonunda, demo sırasında çıkar.

Tahmin: hızlı olmalı, çünkü zor kısım bitti

Teknik hazırlık yapıldıysa planning poker dakikalar sürer. Herkes karmaşıklığı zaten biliyordur, “nasıl” tartışması bitmiştir ve bilinmeyenler önceki aşamada ya çözülmüş ya da madde reddedilmiştir.

Tahmin uzun sürüyorsa bu bir tahmin problemi değildir. Şu üçünden biridir: madde yeterince anlaşılmamıştır, madde çok büyüktür, ya da ekipte o alana hâkim tek kişi vardır. Üçünün de çözümü planning’in içinde değil, dışındadır.

Kapasite: çoğu ekibin atladığı yer

“Altı kişiyiz, on gün var, altmış adam-gün.” Bu hesap yanlış ve her sprint aynı şekilde yanlış. Gerçek hesap şöyle:

Ham kapasite      6 kişi × 10 gün          = 60 adam-gün
İzin / tatil      -1 kişi 3 gün, -1 kişi 2 gün =  -5
Toplantı yükü     ~%10 (daily, review, retro)  =  -6
Üretim desteği    nöbetçi 1 kişi × 10 gün      = -10
------------------------------------------------------
Planlanabilir                                  =  39 adam-gün
Plansız iş tamponu %15                         =  -6
======================================================
Taahhüt edilebilir                             =  33 adam-gün

Altmıştan otuz üçe düştük. Sprint’i altmışa göre planlayan ekip her seferinde taşar ve bunu “kötü tahmin ettik” diye yorumlar. Tahmin sorunu değil, aritmetik sorunu.

Tampon oranını ölçüye dayandır: son üç sprint’te plansız gelen işlerin gerçek yüzdesini hesapla ve tamponu ona eşitle. Tahminle konulan tampon ya çok küçük olur ya da ekip onu boş zaman sanır.

Çekme sistemi: baştan atama yapma

Sprint başında her maddeye bir sahip atamak yaygın bir alışkanlıktır ve iki tarafı da keskin bir bıçaktır.

• Herkes yalnızca ilk işini üstlenir.
• Geri kalan maddeler sprint backlog’unda sahipsiz durur, ama önceliğe göre sıralıdır.
• Biri işini bitirdiğinde durumu günceller ve sıradaki en yüksek öncelikli maddeyi çeker.

Bu ikisinin ortasındaki çözüm pair programming’i planning’in bir parçası yapmak: hangi maddelerin eşli yapılacağını burada işaretle. Junior zor bir madde çektiğinde kiminle eşleşeceğini bilir; senior sıkıcı bir madde çektiğinde öğretmek için eşleşir. Toplam sprint eforunun %20–40’ını eşleşmeye ayırmak, kısa vadede yavaşlatır ama üçüncü aydan itibaren hızı artırır.

QA’i birinci güne çek

Sprint’lerin son iki gününde QA’in boğulması bir kapasite sorunu değil, bir akış sorunudur. Planning’de hedef belirlenmeli: ilk test edilebilir madde 1. günün sonunda QA’e düşmeli.

QA için 1. gün boş gün değildir: test veri setleri, ortam hazırlığı ve test senaryoları o gün yazılır. Bunu planning’de konuşmayan ekiplerde QA sprint’in ilk yarısında bekler, ikinci yarısında yetişemez.

Taahhüt

Taahhüt bir pazarlık değildir. Ekip kapasitesine bakar ve teslim edebileceğini bildiği işi çeker. Teknik riskler önceden çözüldüğü için bu bir tahminden daha güçlüdür.

PO’nun “bir tane daha sığar mı?” sorusuna verilecek cevap şudur: “Sığar, ama karşılığında şunu çıkarıyoruz.” Kapsam eklemenin karşılığı olmayan her planning, sprint ortasında yapılacak bir kavganın provasıdır.

Kontrol listesi

Sonuç

Sprint planning sıkıcı olmalıdır. Burada büyük tartışmalar ve sürprizler çıkıyorsa sorun planning’de değil, ondan öncesindedir. İyi bir oturum kısa bir onay törenidir: “Hazırız, başlıyoruz.”