Sprint Kapasitesi Nasıl Gerçekçi Hesaplanır?
İzinler, toplantılar ve odak kaybı: gerçekçi bir sprint taahhüdü için hesaba katmanız gerekenler ve adım adım bir hesaplama örneği.
Sprint planlamasının en sık tekrarlanan hatası, ekibin her gün tam kapasiteyle çalışacağını varsaymaktır. Sonuç tanıdıktır: sprint sonunda işlerin bir kısmı bir sonraki sprinte devreder, ekip moral kaybeder ve paydaşlar tahminlere güvenmemeye başlar.
Gerçekçi bir taahhüt için kapasiteyi üç adımda hesaplamak yeterli.
1. Müsait günleri çıkarın
İlk adım basit ama sık atlanır: sprint süresince her kişinin kaç gün çalışacağını yazın.
- Planlı izinler
- Resmî tatiller
- Eğitim, konferans veya başka projeye ayrılan günler
İki haftalık bir sprintte 10 iş günü varsa ve bir ekip üyesi 2 gün izindeyse, o kişinin müsait günü 8'dir.
2. Sabit toplantıları düşün
Sprint planlama, günlük toplantılar, inceleme (review) ve retrospektif her sprintte tekrar eder. İki haftalık bir sprintte bunlar kişi başı kabaca 5–8 saat tutar. Bu süreyi kapasiteden önceden düşmek gerekir.
3. Odak oranını belirleyin
Kimse günün tamamını sprint işlerine ayıramaz. E-postalar, destek talepleri, kod incelemeleri ve plansız yardımlar zaman alır. Her kişi için gerçekçi bir odak oranı belirleyin:
- Sadece sprint işine odaklanan bir geliştirici için %70–80
- Mentorluk ve teknik liderlik yapan biri için %40–60
- Destek rotasyonunda olan biri için daha da düşük
Bu oranlar ekipten ekibe değişir; birkaç sprint boyunca gerçekleşen değerlere bakarak kendi oranlarınızı bulmanız en doğrusu.
Örnek hesap
Beş kişilik bir ekip, iki haftalık (10 günlük) sprint, günde 8 saat ve kişi başı 6 saat sprint toplantısı:
| Kişi | İzinli gün | Odak | Müsait saat |
|---|---|---|---|
| Backend geliştirici | 0 | %80 | 59,2 |
| Frontend geliştirici | 2 | %80 | 47,4 |
| Mobil geliştirici | 0 | %70 | 51,8 |
| Test uzmanı | 1 | %85 | 56,6 |
| Teknik lider | 0 | %50 | 37,0 |
Örneğin backend geliştirici için: (10 gün × 8 saat − 6 saat toplantı) × %80 = 59,2 saat.
Toplam yaklaşık 252 saat ediyor. Aynı ekip hiç izin olmadan çalışsaydı kapasite yaklaşık 270 saat olacaktı. Yani bu sprintin kapasitesi normalin %93'ü.
Story point'e çevirmek
Ekibiniz story point kullanıyorsa saatleri doğrudan puana çevirmeyin. Bunun yerine geçmiş hızınızı (velocity) kapasite oranıyla çarpın:
- Son üç sprintin ortalama hızı: 34 puan
- Bu sprintin kapasite oranı: %93
- Önerilen taahhüt: 34 × 0,93 ≈ 32 puan
Bu yöntem, tahmin alışkanlıklarınızı bozmadan izin ve tatil dönemlerini hesaba katmanızı sağlar.
Hesabı otomatik yapın
Bu hesabı her sprintte elle yapmak yerine Sprint Kapasite Hesaplayıcı aracını kullanabilirsiniz. Ekibi bir kez girdiğinizde tarayıcınız hatırlar; sonucu Markdown tablo olarak kopyalayıp Jira ya da Confluence'a yapıştırabilirsiniz.
Kapasite hesabı bir taahhüt değil, bir başlangıç noktasıdır. Asıl değer, ekiple birlikte "bu sprintte gerçekten ne kadar zamanımız var?" sorusunu açıkça konuşmaktır.