Scrum'da Efektif Sprint Planlama(Sprint Planning) Toplantısı Nasıl Yapılır?

Scrum'ın en önemli ve yönetilmesi zor etkinliği olan Sprint Planlama(Sprint Planning) toplantısı, Sprint içinde yapılacak işlerin planlandığı etkinliktir. Sprint planlama Scrum Team ile birlikte yapılır. Planlama toplantısının birinci kısmına Product Owner katılır, ikinci kısmına ise katılmak zorunda değildir ancak ulaşılabilir olmalıdır. Çünkü takım kapasite ve iş önceliğine göre alacağı PBI'lar da danışmak ve bilgi almak isteyebilir.

Sprint Planning, 4 haftalık Sprint için 8 saat, 2 haftalık Sprint için 4 saat ile sınırlıdır. Scrum Master, toplantının yapılmasını ve Development Team'in etkinliğin amacını anlamasını sağlar. Planlama toplantısı Time-Box süresini aşmamalıdır. Eğer takım bu süreyi aşıyorsa eski adıyla Grooming yeni adıyla Refinement(detaylandırma) toplantısı yapabilir. Bu sayede takım planlamada zaman kazanmış olur. Normalde Scrum'ın özünde bu etkinlik yoktur. Fakat takım tahminleme özelliğini daha da iyileştirmek için bu etkinliği yapar.

Planlamanın ilk kısmında PBI'lar Product Backlog'dan öncelik sırasına göre seçildikten sonra sonra Sprint Goal belirlenir ve çıkarılacak Increment netleşir. Planlamanın ikini kısmında ise PBI'lara Task verme ve işi detaylandırma aşamasına geçilebilir.

Planlama toplantısında Sprint sonunda çalışan bir ürün(Increment) olarak ne teslim edilebilir konuşulur. Bu arada takım her Sprint sonu bir Increment çıkarmak zorunda değildir. Takım o Sprint içinde Sprint Goal olarak kendine bir gelişim alanı seçip o alanda kendini o Sprint içinde geliştirme görevi edinebilir. Bu gelişim sonraki Sprint'ler de daha kaliteli Increment çıkarmasına yardımcı olacaktır.

Sprint Planlama şu sorulara cevap verir;
* Başlayan Sprintte Increment olarak ne teslim edilebilir? (Ne Yapacağız)
* Increment'ı teslim etmek için gerekli olan iş nasıl başarılacak? (Nasıl Yapacağız)

Sprint Planlama öncesi Product Owner tarafından öncelik(Priority) sırasına göre hazırlanmış bir Product Backlog vardır. Takım bu Backlog'dan öncelik sırasına göre PBI'ları alır. Takım alacağı iş kapasitesini kendi belirler ve Toplam Size kapasitesini o Sprint için kendi çıkarır. Product Owner, Sprint'te başarılması gereken Sprint Goal hakkında bilgi verir. Tüm süreci takım yönetir ve kapasitesine göre işi alarak o Sprint için kendi sınırını belirler.

Takım iş alırken Product Backlog'daki bütün işleri veya Product Owner'ın almasını istediği bütün işleri almakta mecbur değildir. Fakat işleri seçerken öncelikli olanları almakta mecburdur. Kapasite belirlerken o Sprint içinde ağırlık olarak yapılacak Development işine göre ufak bir matematik hesabı yapabilirsiniz.

Takım Kapasitesini Hesaplamak
Örnekle 9 kişilik bir takımda 1 Tester, 3 Analist ve 4 Developer olsun. Siz Development ağırlıklı bir Sprint geçirecekseniz direk 8 kişiyi saat bazında düşünüp kapasite hesaplarsanız analistlerin fazla kapasitesi Development olarak iş alma kapasitesini yükselteceği için var olan Developer sayısını takım sayısına bölerek daha gerçekçi kapasiteyi bulabilirsiniz.

Developers/Team * Toplam Saat

Örnekle toplam saat kapasitesi 250 olsun. Direk 250 üzerinden Task maliyetlerini düşmeye başlarsanız birde Test ve Analiz Task maliyetleri düşük olursa, çokça Development işi almamız gerekir yanılgısına düşersiniz. Sprint'in ikinci haftası işlerin yetişemeyeceğini Daily Scrum'da hissedersiniz.

Oysaki (Developers/Team * Toplam Saat) yani (4/8*250=125 Saat Development) gibi düşünürseniz en azından daha gerçekçi olur. Bu sayede daha kaliteli ürün çıkarırsınız. Takımın kapasitesi dışında fazladan iş alması hem işleri bitirme konusunda Sprint içinde psikolojik baskı oluşturabilir hemde diğer PBI'lar hızlıca yetişecek diye kalitesiz ürünler ortaya çıkabilir. Bu yüzden gerçekçi olup yapabilecek kadar iş almanız en iyisidir.

Development Team, Sprint'te teslim edeceği PBI'ları planlar ve Sprint Goal'ü oluşturur. Sprint Goal, Sprint sonunda ulaşılacak hedeftir. Kapasite ve kaç Size'lık iş alma süreci netleşip PBI'lar alındıktan sonra Sprint Backlog hazırlama işine geçilir.

Sprint Backlog Hazırlamak(Sprint İş Listesi)
Öncelik sırasına göre PBI'lar Sprint Backlog'da dizilir. Daha sonra her PBI için ne yapılması gerektiği konuşulur ve o PBI Tasklara bölünür. Tasklar anlaşılır ve kısa cümleler olmalıdır. Genelde Task tipleri analiz, test, geliştirme, altyapı, servis, destek, bağımlılık gibi konulara ayrılır. Task üzerinde yetkin olan kişi o Task için saat maliyeti verir. Toplam saat maliyetleri genelde Toplam saat kapasitesine yakın ve fazla aşmayacak şekilde belirlenir. Task'lar da PBI'ın konusu detaya inildiği için gerçekten fazla maliyet çıkıyorsa en alttan önceliğe göre bazı PBI'lar takım tarafından Sprint Backlog'dan çıkarılabilir.

Development Team, toplantıya teknik tavsiye veya uzmanlık tavsiyesi vermek üzere başka kişileri de davet edebilir. Yine aynı şekilde takım Sprint içinde yapabileceğini düşünüyorsa ve kapasitesi varsa Product Backlog'dan Sprint içinde PBI alabilir.

Sonuç olarak Sprint Planlama sonunda, hedefe(Sprit Goal) ulaşmak ve beklenen Increment'i çıkarmak için takım self-organize olarak nasıl çalışacağını ortaya koyabilmelidir.

* Takım tüm Task'ların ve maliyetlerin üzerinden son bir defa tekrar geçmesinin faydası vardır bazen işin gerçek saat maliyeti düşünmek gerektirebilir.

* PBI'ın Done olma kriterini Acceptance Criteria sınırlarını 2 haftalık Sprint için çok iyi belirlemeniz lazım. Bunu belirleyemezseniz Sprint içinde PBI kapsamlarını değiştirmek zorunda kalabilirsiniz.

* Sprint Backlog'un planlama sonrası %70'i çıksa yeterli olacaktır. Sprint içerisinden PBI'lar belli ise Task'lar işi yaparken de verilebilir. Kapasiteye göre Sprint içerisinde Product Backlog'tan PBI alınabilir.

* Planlama sırasında Development Team toplantıya teknik veya uzmanlık tavsiyesi vermek üzere başka kişileri davet edebilir.

* Planlama sonunda Development Team Product Owner ve Scrum Master'a Sprint Goal'e ulaşmak için nasıl kendini yöneten bir takım olarak çalışacağını açıklayabilmektedir.

* Paydaşları Sprint Planning toplantısının ilk kısmına Product Owner'ın alıp gelmesi planlamayı zenginleştirebilir.