Sprint Planlama Toplantısı Nasıl Yapılır? NE Bölümü…

Sprint Planlama Toplantısı’nın ilk bölümü olan NE bölümünü 1 saat ya da altında bir sürede tamamlayabildiniz mi?

Scrum’ı anlayamamış Ürün Sahipleri tarafından kolayca işgal edilebilen toplantının bu bölümünde sıklıkla birkaç hata yapılır. Müşteri ile Sprint içinde yakın ilişki kurmaktan çekinen ya da bunu gerekli görmeyen Ürün Sahipleri müşterinin ihtiyaçlarını Sprint Planlama Toplantısı’nın NE bölümünde dinlemek isterler. Müşteri, toplantıya geldiğinde tüm Scrum Takımı’nın kendini dinlediğini görünce memnun olur. Halbuki ortada yaratılan çok büyük bir israf vardır. Müşteri ihtiyaçlarının Ürün Sahibi tarafından alınması, bunların değerli olup olmadığının belirlenmesi ve İş Listesindeki öncelik ve değer sıralamasının Sprint içinde yapılmış olması gerekmektedir. Ürün Sahibi bu toplantıya önceliği belirlenmiş bir liste ile gelir. Daha iyi olanı ise bu listeyi eski adıyla grooming yeni adıyla refinement aktivitelerinde Geliştirme Takımı üyelerine göstermiş olmasıdır. Elbet son gün son dakika içinde acil işler çıkmış ve listeye girmiş olabilir ve Geliştirme Takımı bunu ilk defa görüyor olabilir. Önemli olan Geliştirme Takımı, Sprint İş Listesini oluştururken onların istediği detay bilgileri doğru bir şekilde verebilmektir.

Burada dikkat edilmesi gereken nokta toplantının NE bölümünün amacından sapıp bir grooming aktivitesine dönüşmemesi ve NASIL bölümü için gerekli zamanın ayrılmış olmasıdır. Bunu yapabilmek içinse gerektiği kadar detaylandırma aktivitesinin yapılmış olması lazım gelir ve mümkün olan en kısa sürede NE bölümünün bitirilmesidir.

Daha önce Hikaye Puanı(Story Point ya da Size), büyüklük, maliyet verdiğiniz İş Listesi Maddelerini toplantının ilk bölümünde gözden geçirdiniz mi?

Detaylandırma aktivitelerinde Hikaye Puanı verilmiş İş Listesi Maddelerini son defa gözden geçirmek iyi bir pratiktir. Hızlı değişimin olduğu çevrelerde bir madde ile ilgili değişim Ürün Sahibi’nin dikkatinden kaçabilir. Bunun önüne geçmek için Scrum Takımı’nın tamamının kısaca bir değerlendirme yapması iyidir. Yine geliştirme tarafında yapılan değişiklikler o işin büyüklüğünü etkileyebilir. Geliştirme tarafında yapılan bu değişikler Ürün Sahibi tarafından bilinemeyebilir. Bu değişiklikler işin maliyetini artırıp azaltabilir dolayısıyla Sprint İş Listesini doğrudan etkileyebilir.

Bir önceki Sprint’te tamamlayamadığınız iş varsa bunlara yeniden Hikaye Puanı(Story Point ya da Size), büyüklük, maliyet verdiniz mi?

Bir önceki Sprint’e aldığınız işlerin tamamını bitirememiş olabilirsiniz. Eğer Ürün Sahibi bu işlerin bitirilmesine öncelik verdiyse bu işlerin kalan bölümüne maliyet verdiniz mi? Bu işlerin test ya da entegrasyon task’ları* kalmış olabilir. Böyle bile olsa yapılması gereken işlere büyüklük verip Sprint Backlog’a eklenmelidir.

*Task: İngilizce görev, iş, ödev anlamlarına gelmektedir. Buradaki anlamı ise bir İş Listesi Maddesi’nin Sprint’e alındıktan sonra Geliştirme Takımı’nın bu maddeyi geliştirmek için daha küçük işler böler. Bu işler task olarak adlandırılmıştır.

Hikaye Puanı verme aktivitesine(Poker Planning) Geliştirme Takımı’nda bulunan her üye katıldı mı?

Hikaye Puanı(Story Point) verme aktivitesine Geliştirme Takımı üyelerinin tamamının katılması gerekir. Bu aktivite şeffaflığın yaratılması ve bilginin paylaşılması için çok önemlidir. Bu aktivite gerçekleştirilirken yapılan iki büyük hata bulunmaktadır.

Birinci hata; İş Listesi Maddesine maliyet verilirken, Bitti Tanımı’ndaki her adım için tek tek maliyet verilmesidir. Bitti Tanımı bir bütün olarak değerlendirilmelidir. Bir İş Listesi Maddesi’nin geliştirme işini gerçekleştirecek kişi bir maliyet verirken bu geliştirmenin testini yapacak kişi test işi için maliyet verir. Bu yanlıştır! İş Listesi Maddesi uçtan uca değerlendirilmelidir.

İkinci hata; farklı Hikaye Puanı veren Geliştirme Takımı üyelerinin verdikleri puana dair düşüncelerini paylaşmamalarıdır. Eğer verilen Hikaye Puanları arasındaki fark çok büyükse bu madde herkeste aynı anlayışı oluşturmuyor demektir. Bu da maddenin açık olmadığına ya da yapılacak işin sadece bazı Geliştirme Takımı üyelerince bilindiğini gösterir. Geliştirme Takımı üyeleri verdikleri Hikaye Puanlarını neden verdiklerine dair düşüncelerini ve konuyla ilgili bilgilerini paylaşmalıdırlar. Böylece ortak anlayış oluşturulacak ve Sprint içindeki ilerleyiş daha pürüzsüz gerçekleşecektir.

Ürün Sahibi, Hikaye Puanı, maliyet, büyüklük verme aktivitesine müdahale etti mi?

Ürün Sahipleri birkaç nedenden dolayı maliyet belirleme aktivitesine müdahale edebilirler. Bunlar;

• Çevik Dönüşümün başladığı yerlerde bu dönüşüm ile statüko kaybeden eski kaynak yöneticisi, takım lideri, iş biriminde yönetici olan ve Geliştirme Takımı’yla yanyana olmak istemeyen yeni Ürün Sahipleri’nin genel direnci
• Bunu yapmaması gerektiğini bilmemesi
• Ürün Sahibi’nin bir Sprint’te daha fazla iş bitirilmesi amacı ve gerekli Ürün Sahibi reflekslerini kazanamamış olması
• Ürün Sahibi, Geliştirme Takımı üyelerinin verdikleri Hikaye Puanları’nın doğruluğuna güvenmiyorsa, Geliştirme Takımı üyeleri işlere verilen Hikaye Puanlarını kasıtlı olarak büyük söylüyorsa

Burada iyi Scrum Master’ın kuralı hatırlatıp araya girmesi gereklidir. Herhangi bir nedenden dolayı maliyet verme aktivitesine müdahelede bulunmak şeffaflığa büyük zarar verecektir. Öncelikle Scrum Takımı’nın hızı doğru olmayacaktır. Daha sonra Geliştirme Takımı üyeleri kendileri commitment(Türkçe karşılığını çok düşündüm belki söz vermek olabilir) vermediği için işi sahiplenmeyecek ve Sprint içinde alınması gereken acil aksiyonları almayacaklardır. Ürün Sahibi’nin baskıcı etkisine karşı Geliştirme Takımı bir tepki gösterecek, bu da işi sahiplenmeme olacaktır.

Bir diğer riskse alınan fazla işlerden dolayı Sprint sonunda işlerin tamamı bitirilememiş olacak ve Geliştirme Takımı üyeleri kendilerini kötü hissedeceklerdir. Scrum’ın içinde var olan fakat çoğu kişinin farkında olmadığı bir özelliği olan kişilere, takımlara ulaşılabilir hedefler vermek ve bunu başarmalarına yardımcı olmak yaklaşımı yıkılmış olacaktır. Bütün bu nedenlerden dolayı Ürün Sahibi’nin verilen maliyete müdahalede bulunmaması iyi bir pratik olacaktır.

Eğer Ürün Sahibi, Geliştirme Takımı üyelerine güvenmiyorsa bunun konuşulması gereken yer Sprint Retrospektif Toplantısı’dır. Sprint Retrospektif Toplantısı’nda tüm Scrum Takımı’yla açık bir şekilde bu konu tartışılmalıdır. Böyle bir yaklaşım sergilemenin nedenleri irdelenmeli ve sorun bulunmalıdır. Scrum Master’ın sorunu bulması ve çözülmesi için taraflara yardımcı olması gerekir.

Ürün Sahibi, Geliştirme Takımı’na kapasitesinin üzerinde iş alması için müdahelede bulundu mu?

Bu konu yukarıda irdelediğimiz konunun uzantısı şeklindedir. Ürün Sahibi, bir önceki maddede bahsettiğimiz nedenlerle Geliştirme Takımı’nı bir Sprint’te bitirebileceğinden fazla iş almaya zorlayabilir. Sonuçta Geliştirme Takımı işi bitiremeyecek ve herkes için üzücü bir Sprint geçirilecektir. Ne Ürün Sahibi’nin bitirileceğini düşündüğü işler bitecek ne de Geliştirme Takımı belirlenen hedefe ulaşabilecektir, Scrum Master ise bu iki rol arasında mekik dokuyacak ve işlerin bitmesi, orta yolu bulmak için çalışacaktır. Herkes için verimsiz bir Sprint olacaktır.

Geliştirme Takımı Sprint Planlama Toplantısı’nda işleri bitireceğine dair söz verirken önceki Sprint’lerde ortaya çıkan metrikler göz önünde bulunduruldu mu?

Bir Sprint’te bitirilebileceğine inanılan kadar İş Listesi Maddesi konuşulduktan sonra Geliştirme Takımı üyeleri önceki Sprint’lerin metriklerine kısaca göz atmalıdır. Örneğin önceki Sprint’lerin hız ortalaması 120 Hikaye Puanıysa 300 Hikaye Puanlık iş alınmamalıdır. Hatta 300 Hikaye Puanlık işin konuşulması başka bir hatadır. Scrum Takımı kendini sınamak isteyebilir ve bu Sprint’i diğerlerine göre daha yoğun şekilde çalışarak geçirmek isteyebilir. Bu durumda 140-150 hikaye puanlık iş alınabilir fakat bu bile risklidir. Fakat riski alan Geliştirme Takımı olduğu ve kendileri söz verdiği için bu desteklenebilir bir davranıştır.

Aynı şekilde Geliştirme Takımı bir önceki Sprint çok yoğun bir çalışmadan çıkmış olabilir ve bu Sprint’e alınan işlerden bazılarının riskinin çok yüksek olduğunu düşünebilir. Bu nedenle ortalamanın altında yani 100 hikaye puanlık iş almak isteyebilir. Bu konuyla ilgili Geliştirme Takımı’nın nedenlerini dinleyerek kararlarına saygı duymak gerekir.

Bakılabilecek diğer bir metrikse çalışma saatleridir. Örneğin bayram tatilinin olduğu bir Sprint’e girilecektir. Bayram tatilinden dolayı çalışma saatlerinde azalma olabilir. Yine önceki Sprint’lerdeki çalışma saatlerine oranlayarak yeteri kadar iş alınabilir.

Geliştirme Takımı üyelerinin sayısı da önemli bir metriktir. Örneğin Geliştirme Takımı üyelerinden bazıları izinli olabilir ya da Sprint içinde birkaç günlüğüne işe gelemeyecek olabilir. Bunların hepsi Sprint’i etkileyecek konulardır ve göz önünde bulundurulmalıdırlar.

Ürün Sahibi, Sprint Planlama Toplantısı’na bir Sprint Hedefi ile geldi mi? Eğer gelmediyse Scrum Takımı bir Sprint Hedefi belirledi mi?

Scrum Klavuzu’nda aşağıdaki ifadeye yer verilir.

“Geliştirme Takımı’nın İş Listesi maddelerini büyüklendirmesinden sonra oluşturulan Sprint İş Listesi, Sprint içinde tamamlanacaktır. Scrum Takımı, Sprint Hedefini belirler. Sprint Hedefi, Sprint için seçilen İş Listesi maddelerinden belirlenecektir ve Geliştirme Takımı’na neden bir artım oluşturdukları hakkında rehberlik sağlayacaktır.”

Buna göre Sprint Hedefi, Scrum Takımı tarafından herkesin katılımıyla belirlenir. Bazı Scrum uygulayıcıları tarafındansa Sprint Hedefi’nin Ürün Sahibi tarafından belirlenmesi gerektiği savunulur çünkü sürüm planlamasını yapan Ürün Sahibi’dir. Her ne kadar sürüm planlamasının sorumluluğu Ürün Sahibi’nde olsa da sürüm planlamasının gerçekleşebilmesi için Geliştirme Takımı’nın fikirleri gerçeğe dönüştürmesi gerekmektedir. Bu nedenle Scrum’ın yaratıcılarının da belirttiği gibi Sprint Hedefi’nin, Sprint Planlama Toplantısı’nın NE bölümünde belirlenmesi daha iyi bir pratik olacaktır.

Sprint sırasında planlamaya dahil etmediğiniz işler almak zorunda kaldınız mı? Bu işleri metriklerinize yansıttınız mı? Yaptığınız Sprint Planlama Toplantısı’nda gelecek Sprint’te yine acil işler olabileceğini düşünüyorsanız bunun için bir süre ayırdınız mı?

Bu konu bir “Scrum Ama” konusudur ve çalıştığınız organizasyon ve takıma göre birçok değişiklik gösterebilmektedir. İdeal Scrum Takımlar’ında Sprint içinde gelen işler bir sonraki Sprint’e kalır ve bir sonraki Sprint’te gerçekleştirilir. Gerçekte ise işler bu kadar kolay olmayabilir. Gelen iş ister üretim sisteminde bir hata olsun ister organizasyonun para kaybettiği bir açık olsun anında düzeltilmesi gerekebilir. Bu şekilde gelebilecek işlerin Sprint Planlama Toplantısı’nda düşünülmesi ve Sprint İş Listesi’nin buna göre hazırlanması mantıklı bir davranıştır. Bu şekilde gelen işlerin ölçülmesi ve frekansının belirlenmesi planlama işinin daha doğru yapılmasını sağlayabilir. Önceki Sprint’lerde acil gelen işler ölçülebilir ve gelecek Sprint’lerde bu işler için gerekli zaman ayrılabilir. Eğer gelen acil iş çok büyükse Ürün Sahibi Sprint İş Listesi’nden bazı işlerin düşürülmesini talep edebilir. Düşürülen bu işlerin yerine gelen acil iş Geliştirme Takımı tarafından gerçekleştirilebilir. Eğer gelen iş çok çok büyükse ve Sprint’te diğer işlerin tamamlanmasına zaman kalmayacaksa Sprint iptal edilebilir ve yeni bir planlamayla yeni bir Sprint’e başlanabilir.