Sprint Kaosu: Bir İstanbul Fintek Ekibinin Story Point Savaşı

Saat 09:40. İstanbul, Levent'te bir fintek şirketinin geliştirme ofisi. Günlük Scrum daha yeni bitmişti ama toplantı odasından çıkan yüzler her zamanki gibi değildi. Sprint'in 6. günüydü ve backlog'da hâlâ bitmemiş 7 iş kalemi vardı; sprint'in bitmesine 4 gün kalmıştı.

Durum: Kapasitenin Üzerinde Bir Sprint

Ekip 6 kişiydi: 4 geliştirici, 1 test mühendisi, 1 Scrum Master. Önceki üç sprint'te ortalama tamamladıkları iş yükü, story point cinsinden istikrarlı bir bant içindeydi. Ama bu sprint'te ürün yöneticisi (PO), üst yönetimden gelen bir ödeme entegrasyonu talebini son anda backlog'a eklemiş, ekip de itiraz etmeden kabul etmişti.

Neden itiraz edilmedi? Ekiple sonradan yapılan retrospektifte üç neden ortaya çıktı:

• Otorite baskısı: Talep doğrudan CEO'dan geliyordu, PO da bunu ekibe "yukarıdan geldi, tartışmaya açık değil" diye iletmişti.
• Ölçmeme alışkanlığı: Ekip, sprint planlamada "kabaca sığar" diyerek gerçek kapasite hesaplaması yapmıyordu — izinler, toplantılar, teknik borç düşülmüyordu.
• "Hayır" diyememe kültürü: Daha önce bir geliştirici kapasite konusunda itiraz ettiğinde, "çözüm odaklı olmuyorsun" geri bildirimi almıştı. Bu, ekipte sessiz bir öğrenilmiş çaresizlik yaratmıştı.

Fark Ediş Anı

Test mühendisi, 4. günün günlük Scrum'ında şunu söyledi: "Bugüne kadar test edebileceğim hiçbir şey bitmedi, ama önümde 3 iş kalemi test kuyruğunda bekliyor." Bu cümle, Scrum Master için alarm zilleriydi — iş bitmeden test kuyruğa yığılıyorsa, sprint sonunda kimse tahmin edemez ne kadarının teslim edilebileceğini.

Scrum Master'ın İlk 24 Saatte Attığı Adımlar

Kök Nedene İnmek: Retrospektifte Ne Konuşuldu

Sprint bittiğinde retrospektifte ekip, sorunun tek bir sprint'ten ibaret olmadığını fark etti. Asıl sorun, kapasite planlamasının hiç sistematik yapılmamasıydı. Scrum Master, ekiple birlikte basit bir kapasite şablonu oluşturdu:

• Adım 1: Her kişinin sprint içindeki müsait gün sayısını hesapla (izin, eğitim, toplantı yoğunluğu düşülerek).
• Adım 2: Geçmiş 3 sprint'in ortalama tamamlanan story point'ini referans al (tahmin değil, gerçekleşen veri).
• Adım 3: Yeni sprint kapasitesini bu ikisinin oranına göre belirle; PO'ya "şu kadar kapasitemiz var, önceliğe göre seç" diye net bir çerçeve sun.
• Adım 4: Sprint ortasında beklenmedik bir talep gelirse, "neyi çıkarıyoruz?" sorusunu birlikte cevapla — "hem bunu hem onu" seçeneği yok.

Üç Sprint Sonunda Toparlanma

İlk sprint'te (kapasite planlamasının uygulandığı ilk sprint) ekip hâlâ temkinliydi, hedefin biraz altında iş aldı. İkinci sprint'te güven artmaya başladı, tahminler gerçekleşenle örtüşmeye yaklaştı. Üçüncü sprint sonunda ekip, sprint review'da PO'ya ilk kez net bir cümle söyleyebildi: "Bu iş sprint'e sığmaz, ama şu alternatifi önerebiliriz." Bu cümle, ekibin güvenini yeniden kazandığının somut göstergesiydi.

Bu Vakadan Çıkan Dersler

• Kapasite baskısı çoğu zaman kötü niyetten değil, ölçülmemiş varsayımlardan gelir.
• "Hayır" demek, işbirliğine kapanmak değildir; net bir alternatif sunmaktır: "Bu olmaz ama şu olur."
• Scrum Master'ın rolü burada arabuluculuk değil, görünürlük yaratmaktı — veriyi masaya koyunca tartışma duygudan çıkıp gerçeğe döndü.
• Toparlanma bir gecede olmaz; bu ekip için üç sprint sürdü ve bu normaldi.

Sizin İçin Tartışma Soruları

• Sizin ekibinizde "hayır" diyememe kültürü var mı? Varsa, bu kültür nereden besleniyor?
• Ürün sahibiyle kapasite konusunda nasıl sınır çizersiniz? Elinizde somut bir veri/şablon var mı, yoksa "hissederek" mi karar veriyorsunuz?
• Aşırı yüklenmiş bir sprint'i fark ettiğinizde ilk 24 saatte ne yaparsınız? Bu derste anlatılan 4 adımdan hangisini kendi ekibinize uyarlayabilirsiniz?