Sprint Süresi: İki Hafta Değil, Geri Bildirim Hızı

Sprint süresi ne işe yarıyor?

Sprint süresinin iki işi var. Birincisi, önceliği bir süre sabit tutmak. Ekip iki hafta boyunca neyin önemli olduğunu her sabah yeniden tartışmadan çalışabilsin. İkincisi, bir döngüyü kapatmak. Sprint sonunda çalışan bir şey gösterilir, kullanıcı ona bakar, ekip yanlış yolda olup olmadığını öğrenir.

Serinin ilk bölümünde şunu yazmıştım: iki haftalık döngüler tahmini isabetli yapmaz, sadece yanıldığında bunu altı ay yerine iki hafta içinde öğrenmeni sağlar. O cümlede “iki hafta” bir sayı değil, bir örnekti. Asıl soru, yanıldığını ne kadar sürede öğrendiğin. Sprint süresi bu sürenin sadece bir parçası.

22 Mart’taki butonun hikâyesi bunu gösteriyor. Talep 16 Ocak’ta geldi. 22 Ocak planning’ine hazır değildi. 12 Şubat planning’inde sprint doluydu. 4 Mart’ta sprint’e girdi, 6 Mart’ta bitti ve 22 Mart’taki review’ı 12 iş günü bekledi. İki günlük iş, kullanıcının önüne dokuz haftadan fazla bir sürede çıktı. Bekleme süresinin iki parçası doğrudan sprint uzunluğundan geliyordu: planning’i beklemek ve review’ı beklemek.

Sahadan: üç süre, sekizer sprint

O review’dan sonra retroya bir öneriyle girdim: bir haftalık sprint. Mantığım basitti. Döngü kısalırsa bekleme kısalır, geri bildirim hızlanır. Ekipte iki kişi itiraz etti, “deneyelim, ölçelim” dedik. Bu yazıdaki en değerli karar buydu, benim önerim değil.

Üç dönemi karşılaştırdık, her biri sekiz sprint:

• Üç hafta: Ekim 2023 – Mart 2024 (son sekiz sprint).
• Bir hafta: 1 Nisan – 24 Mayıs 2024.
• İki hafta: 27 Mayıs – 13 Eylül 2024.

“Somut geri bildirim”i dar tanımladık: review notlarında “şunu değiştirin”, “bu yanlış” ya da “bunu da ekleyin” diye bir maddeye dönüşen her cümle. “Güzel olmuş” sayılmadı. Aylık sayı, review başına sayının ayda kaç review yapıldığıyla çarpımı: üç haftada 6,1 × 1,44; bir haftada 1,4 × 4,33; iki haftada 4,8 × 2,17.

Bir haftalık sprint’in ilk iki haftası harikaydı ve bu, sonraki kararı geciktirdi. Biten iş review’ı ortalama iki gün bekliyordu; üç haftalık dönemdeki 7,5 günün yanında bu bir zafer gibi görünüyordu. Ekip kanalına “döngü dörtte bire indi” diye yazdım. Yanlış sayıya bakıyordum. Bekleme süresi, biten işin review’a ne kadar sürede ulaştığını söylüyordu; review’da onu gören biri olup olmadığını söylemiyordu. İkinci sayıyı ancak dördüncü haftada, odadaki boş sandalyeleri saydığımda tutmaya başladık. Bu yüzden tablodaki en önemli satır ortadaki değil, kalın olan: ayda kaç somut geri bildirim aldığımız.

Üç hafta neden bırakıldı?

Üç hafta ekibe rahat geliyordu. Taşan madde oranı makuldü, planning’de acele yoktu. Sorun iş tarafındaydı. Aracı kurum işinde öncelik piyasayla ve regülasyonla değişiyor. Bir halka arz takvimi, bir SPK duyurusu, bir kampanya. Üç hafta boyunca önceliği sabit tutmak mümkün olmadı. Sprint başına ortalama 2,6 kez sprint ortasında öncelik değişti. Her değişiklik yarım kalmış bir madde ve bir planning tekrarı demekti.

Üç haftalık sprint aslında üç haftalık değildi. Kâğıt üzerinde üç hafta, pratikte bir buçuk haftalık iki parça ve arada bir kavga.

Bir hafta neden bırakıldı?

Bir haftayı ben istemiştim, bırakma kararını da ben verdim. Üç sebep vardı.

Seremoni yükü küçülmedi. Hesap şöyleydi:

                 3 hafta   2 hafta   1 hafta
planning           3,0       2,0       1,5
grooming           3,0       2,0       1,0
review             1,5       1,0       1,0
retro              1,5       1,0       1,0
daily (15 dk)      3,75      2,5       1,25
----------------------------------------------
toplam            12,75      8,5       5,75
kapasite (saat)   120        80        40
oran              %10,6     %10,6     %14,4

# not: planning ve review sprint kisalinca orantili kisalmiyor.
# bir saatlik review'in yarim saati hazirlik ve baglam kurmak.

Planning bir buçuk saatin altına inmedi, çünkü her hafta aynı bağlamı yeniden kurmak gerekiyordu. Review da bir saatin altına inmedi, çünkü gösterecek şey az olsa bile toplantının açılışı, ekran paylaşımı ve soru turu aynı kalıyordu. Ekip her Pazartesi planning’e, her Cuma review’a giriyordu. Mehmet’in üçüncü haftadaki retro notu tek satırdı: “Toplantılar arasında çalışıyoruz.”

İşler sığmadı. Maddelerin %38’i bir haftaya sığmayıp sonraki sprint’e taşındı. Gösterilebilir bir dilim bizde genelde üç ile altı gün sürüyordu. Beş iş günlük sprint’te altı günlük iş taşar; taşan iş review’da yarım gösterilir, yarım gösterilen iş geri bildirim üretmez.

Review odası boşaldı. Asıl darbe buydu. İlk hafta review’a çağrı merkezinden dört kişi geldi. Beşinci haftada bir kişi geliyordu. Gülay Hanım dürüst davrandı: “Her hafta gelemeyiz. Gösterecek bir şey biriktiğinde çağırın.” Bizim döngümüz bir haftaya inmişti. Kullanıcının döngüsü inmemişti. Geri bildirimin hızını en yavaş katılımcı belirliyordu ve o katılımcı gelmeyi bırakmıştı.

İki hafta neden kaldı?

İki hafta bir orta yol olduğu için değil, üç ayrı sınırın arasına düştüğü için kaldı. Öncelik değişikliği sprint başına 0,9’a indi; iş tarafı iki haftayı tutabiliyordu. Taşan madde %12’ye indi; gösterilebilir bir dilim iki haftaya rahat sığıyordu. Review’a ortalama 3,8 kullanıcı geldi; Gülay Hanım’ın ekibi iki haftada bir gelmeyi takvimine koyabildi. Ayda aldığımız somut geri bildirim üç dönemin en yükseğiydi: 10,4.

Nasıl olmalı: süreyi seçen üç soru

Denemelerden sonra süre seçimini üç soruya bağladık. Başka bir ekipte cevap bir hafta ya da üç hafta çıkabilir. Soruların kendisi değişmiyor.

Sprint süresi ile değişen başka şeyler de var ve karar verirken onları da hesaba katmak gerekiyor. Backlog Refinement bölümündeki T-shirt ölçeğinde XS “1 sprint” demekti. Bir haftalık dönemde XS bir haftaya, üç haftalık dönemde üç haftaya denk geliyordu. Aynı etiket, üç katı farklı bir iş anlamına geliyordu ve bunu ancak ikinci ayda fark ettik. Grooming’deki ufuk da süreyle kısalıyor: “+3 sprint ilerisi” bir haftalık sprint’te sadece üç hafta ileri demek. Ekibin görebildiği yol haritası o dönemde neredeyse kayboldu.

Geçişi nasıl yaptık?

Süre değişikliğini bir sprint’in ortasında değil, bir sprint’in bitişinde yaptık ve o sprint’i ne uzattık ne kısalttık. Değişiklikten bir hafta önce üç şey yapıldı: review davetleri yeni takvimle yeniden gönderildi, T-shirt ölçeğinin gün karşılıkları yeniden yazıldı ve PO iş tarafına “öncelik değişikliği artık sprint sınırında konuşulacak” notunu geçti. Üçüncüsü en çok işe yarayanıydı. İki haftalık dönemde öncelik değişikliğinin 0,9’a inmesinin bir kısmı sürenin kendisinden, bir kısmı o nottan geldi. Hangisinin ne kadar etkilediğini ayıramadım; ikisini birlikte değiştirdik.

Nasıl bozuluyor?

İkinci madde bizde bir ara konuşuldu ve iyi ki yapmadık. Aynı gün cevap bekleyen iş bir haftalık sprint’i de bekleyemez. O işin cevabı daha kısa sprint değil, ayrı bir akış. Bunu Scrum mu, Kanban mı bölümünde anlattım.

Bir hata daha: üç haftalık dönemde sürüm de üç haftada bir çıkıyordu. Biten iş sadece review’ı değil, canlıyı da bekliyordu. 22 Mart’taki butonun asıl gecikmesinin bir kısmı buydu. İki haftaya geçerken sürümü haftalık bir trene bağladık. Sprint artık planlama ve geri bildirim ritmi; canlıya çıkma ritmi değil. Bu ayrımı daha önce yapsaydık bir haftalık denemeye belki hiç gerek kalmazdı.

Son tuzak süreyi sık değiştirmek. Her değişiklik geçmiş sprint’lerle karşılaştırmayı sıfırlıyor. Bir haftalık sprint’te 20 puan, iki haftalık sprint’te 40 puan etmiyor; seremoni yükü ve taşan iş oranı farklı. Denemeden sonra kendimize bir kural koyduk: süreyi en az altı ay değiştirmiyoruz. Mayıs 2024 sonundan bu yana değiştirmedik.

Ne izlemeli?

• İş bitiminden kullanıcı geri bildirimine geçen süre. Sprint süresinin gerçek etkisi bu sayıda.
• Review’a gelen kullanıcı sayısı. Üç sprint üst üste düşüyorsa döngü kullanıcı için fazla sık ya da fazla boş.
• Ayda somut geri bildirim. Review başına değil, ay başına say; yoksa kısa sprint kendini iyi gösterir.
• Seremoninin kapasiteye oranı. %12’yi geçiyorsa toplantılar arasında çalışıyorsunuz.
• Taşan madde oranı ve sprint ortası öncelik değişikliği. Biri süre kısa, diğeri süre uzun diyor.

Kontrol listesi

Sonuç

Gülay Hanım’ın “biz bu arada Excel’le çözdük” cümlesi bana üç haftanın uzun olduğunu söyledi. Ben de bunu “ne kadar kısa o kadar iyi” diye okudum. Bir haftalık deneme bu okumanın yanlış olduğunu sekiz sprint’te gösterdi: döngüyü kısalttık, kullanıcıyı kaybettik.

Bugün iki haftalık sprint’le çalışıyoruz ve bunun sebebi Scrum Kılavuzu’nun ya da sektör alışkanlığının iki hafta demesi değil. İş tarafının önceliği tutabildiği süre, ekibin bir dilimi bitirdiği süre ve kullanıcının gelebildiği sıklık bizde iki haftada kesişiyor. Bu üçünden biri değişirse süre de değişir.

Doğru sprint süresi, kullanıcının gelmeye devam ettiği en kısa süredir.