Bölüm 10: Sprint Planning (Sprint Planlama) Toplantısı Nedir? 📅

Sprint Planning süreci Release Planning tamamlandıktan sonra başlatılır. Takım Product Backlog’taki Story’leri Sprint Backlog’a taşır. Bunları bölerek her biri 8 saatten daha az bağımsız tasklar halinde gruplandırır. Ayrıca, hikayelerin risk değerlendirmesini de yapar ve Sprint ilerledikçe risklerin nasıl ele alınacağına dair hızlıca bir plan üzerinde anlaşıp karar verirler. Sprint’in kapasitesi saat cinsinden, velocity planlaması ise efor tahminleme sürecinde belirlediğimiz story point cinsinden yapılır.

Test ekiplerinin bu süreçte yer alması gerektiğine inanıyorum fakat kurum büyüklüğüne ve organizasyon yapısına göre test ekipleri olmayabilir veya sadece Sprint sonrasında dahil olmaları istenebilir. Benim tavsiyem testçilerin hem release planlamada hem de her bir Sprint koşulurken aktif rol almaları. Story yazımında ve DoD kriterlerinde çok önemli katkıları olacaktır.

Sprint Backlog küçük olması nedeniyle oluşturulması ve yönetilmesi kolaydır ancak bu, ekibin kapasitesi ve eldeki kaynaklar hakkında stratejik olarak düşünmeden geliştirilebileceği anlamına gelmez. Bir takıma kaldırabileceğinden daha fazla iş atarsanız, Release toplantısında belirlenen milestoneları (önemli tarihler) kaçırabilirsiniz. Bu nedenle Scrum Master, takımın yeteneklerini iyi bir şekilde tahmin ederek neler yapabileceğini bilmeli ve onlara rehberlik etmelidir.

Bu bölümde Story’leri Task’lara böldük, hepsine saat cinsinden birer süre atadık ve ekibe paylaştırdık. Bu arada belirteyim, bu işlemi sadece 1 Sprint için gerçekleştiriyoruz. Henüz takımın tam kapasite ne kadar verimli çalışabileceğini bilmiyoruz. Takımın tam kapasite çalışması ve takım ruhunu yakalaması bir kaç Sprint sürecektir. İlk Sprint’i koşmaya başlayalım 🏃‍♂️ 🙂

Bölüm 11: Sprint Nedir, Nasıl Yönetilir? 🏃‍♂️🔁 ↪

Bir önceki bölüme göz atmak ister misiniz?
Bölüm 9: Release Planning (Release Planlama) Toplantısı Nedir? 📅 ↩