Gönderiler

Gerçekten işe yarayan sprint planlama toplantıları nasıl yapılır

Sprint planning, her sprinti başlatan Scrum seremonisidir. Ekip neyi inşa edeceğine, neden önemli olduğuna ve kabaca nasıl yapacaklarına karar verir. İyi çalıştığında herkes hizalanmış şekilde ayrılır. Çalışmadığı zaman ise iki saatlik kafa karışıklığının ardından iki haftalık kaos yaşanır. Çoğu ekip sprint planning yapar (Scrum Alliance'a göre yaklaşık %86), ancak birçoğu bunu gerçek bir planlama konuşması yerine backlog okuma oturumu olarak ele alır. İşte doğru yapmanın yolu.

Sprint planning aslında ne üretir

Sprint planning'in çıktısı üç parçadan oluşan Sprint Backlog'dur:

• Ekibin bu sprintin neden önemli olduğunu belirten kısa bir ifade olan Sprint Goal
• Ekibin tamamlamaya söz verdiği seçilmiş backlog öğeleri
• Ekibin bu öğeleri çalışan bir artışa nasıl dönüştüreceğine dair bir teslimat planı

Sprint Goal, çoğu ekibin atladığı parçadır ve en önemlisidir. Bu olmadan sprint, tutarlı bir yönü olmayan, birbiriyle ilgisiz görevlerden oluşan bir torbaya dönüşür.

Odada kimler olmalı

Tüm Scrum Takımı katılır:

Rol	Sprint planning'de ne yaparlar
Product Owner	Önceliklendirilmiş backlog öğelerini sunar, Sprint Goal'u önerir, kapsamı müzakere eder
Scrum Master	Toplantıyı kolaylaştırır, zaman sınırını korur, engelleri kaldırır
Geliştiriciler	Taahhüt edebilecekleri işi seçerler, uygulamayı planlarlar, hikayeleri görevlere ayrıştırırlar

Konu uzmanları veya paydaş tarafları, katkılarına ihtiyaç duyulduğunda davet edilebilir, ancak onlar konuktur, karar verici değil. Yaygın bir anti-kalıp: geliştiricileri "temsil etmesi" için yalnızca bir veya iki ekip üyesini göndermek. İşi yapan kişiler planlama konuşmasının parçası değilse, onlara verilen taahhütler nadiren tutarlı olur.

Toplantı yapısı

Toplantı, hedef belirlenmesinden görev düzeyinde planlamaya doğal bir akışa sahiptir.

1. Sprint Goal'u belirleyin

   Product Owner bu sprintin neden önemli olduğunu ve hangi değeri sunması gerektiğini önerir. Ekip bunu net bir Sprint Goal'a dönüştürmek için birlikte çalışır. Bir başlangıç noktasına ihtiyacınız varsa, sprint goal oluşturucuyu deneyin. Backlog ile değil, buradan başlayın. Hedef, diğer her şeye yön verir.

2. Kapasiteyi gözden geçirin

   Herhangi bir iş seçmeden önce, gerçek müsaitliği kontrol edin. Kim tatilde? Kim nöbetçi? Güvenilir bir yaklaşım: son üç sprintinizin velocity ortalamasını bir sprint velocity hesaplayıcı ile alın, ardından bilinen kapasite değişikliklerine göre ayarlayın.

3. Backlog öğelerini seçin

   Product Owner, en yüksek öncelikli öğeleri gözden geçirir (bunlar zaten rafine edilmiş ve tahmin edilmiş olmalıdır). Geliştiriciler, kapasitelerini ve Definition of Done'ı göz önünde bulundurarak tamamlayabileceklerinden emin oldukları öğeleri seçerler. Bu bir müzakere sürecidir, yukarıdan aşağı bir atama değil.

4. Görevlere ayrıştırın

   Seçilen her öğe için geliştiriciler işi daha küçük görevlere böler, ideal olarak bir gün veya daha kısa sürede tamamlanabilir olanlara. Gizli karmaşıklık ve bağımlılıklar, sprint ortası sürprizlere dönüşmeden önce burada ortaya çıkar.

5. Sprint Backlog'u onaylayın

   Ekip büyük resmi gözden geçirir: Sprint Goal, seçilen öğeler, teslimat planı. Herkes odadan sprintin ne hakkında olduğunu ve ilk önce neyin üzerinde çalışacaklarını açıklayabilecek durumda ayrılmalıdır.

Ne kadar sürmeli

Scrum Guide maksimum süreleri belirler, hedefleri değil:

Sprint süresi	Maksimum planlama süresi
1 hafta	2 saat
2 hafta	4 saat
3 hafta	6 saat
4 hafta	8 saat

Pratikte, 2 haftalık sprintler yürüten çoğu ekip, backlog önceden iyi rafine edildiğinde planlamayı 60-90 dakikada tamamlar. Sürekli olarak tam zaman sınırını aşıyorsanız, bu bir rafinasyon sorunudur, planlama sorunu değil.

Tahminleme nereye oturur

Ekiplerin sıklıkla hata yaptığı yer burasıdır. Tahminleme, sprint planning'den önce, backlog rafinasyonu sırasında yapılmalıdır, toplantının başında değil. Planning Poker'ı yaratan Mike Cohn, tahminleme için iki iyi zaman belirler:

1. Hikaye yazma atölyelerinden sonra, 20-50 yeni öğenin boyutlandırılması gerektiğinde
2. Düzenli rafinasyon oturumları sırasında, öğeler sprint boyunca netleştirildikçe

Ve bir kötü zaman: sprint planning'in başında. O noktada Product Owner'ın yeni tahminlere göre öncelikleri ayarlaması için çok geçtir ve zihinsel olarak uygulama moduna geçen geliştiriciler yüksek seviyeli göreceli boyutlandırmada zorlanır. Backlog'un üst kısmı sprint planning'e zaten tahmin edilmiş olarak geldiğinde, toplantı bir tahminleme tartışması yerine bir seçim alıştırmasına dönüşür ("bu tahmin edilmiş işin ne kadarı kapasitemize sığar?"). Bu, 90 dakikalık bir oturum ile 3 saatlik bir oturum arasındaki farktır. Ekibiniz tahminleme için planning poker kullanıyorsa, bu oturumları rafinasyon sırasında yapın. Kollabe gibi araçlar asenkron tahminleme destekler, böylece ekipler tüm grubu bloke etmeden kendi zamanlarında tahmin yapabilir.

Sprint planning'i raydan çıkaran hatalar

Yetersiz backlog hazırlığı. Belirsiz, rafine edilmemiş hikayelerle planlamaya girmek, uzun ve sinir bozucu toplantıların bir numaralı nedenidir. Kabul kriterleri toplantıdan önce net değilse, toplantı sırasında daha net olmayacaktır. Sprint Goal yok. Bir hedef olmadan, kapsam daraldığı zaman ödün verme kararları almanın yolu yoktur. Tutarlı bir sprint yerine birbirinden kopuk bir görev listesiyle kalırsınız. Aşırı taahhüt. Düzenli olarak tamamlanmamış işin %30-40'ını bir sonraki sprinte taşıyorsanız, ekibin teslim edebileceğinden fazlasını üstleniyorsunuz demektir. Çoğu ekip sprintinin %15-25'ini plansız iş, toplantı ve genel giderlere kaybeder. Bunu hesaba katın. "Nasıl" kısmını atlamak. Hikayeleri uygulama yaklaşımını tartışmadan seçmek, sprint ortasında sürprizlerin ortaya çıkması anlamına gelir. Yaklaşım üzerine beş dakika bile bunların çoğunu önler. Durum toplantısı gibi davranmak. Sprint planning ileriye dönüktür. Geçen sprintte olanları güncellemek için zaman harcıyorsanız, bu sprint review veya retrospektife aittir.

Sprint planning'i zamanla iyileştirmek

Bir şeyi iyileştiriyorsanız, backlog rafinasyonu olsun. Scrum Guide, toplam sprint saatlerinin %5-10'unu rafinasyona harcamanızı önerir. Hikayeler planlamaya net kabul kriterleri, bilinen bağımlılıklar ve mevcut tahminlerle geldiğinde, toplantı neredeyse kendi kendine yürür. Bunun ötesinde:

• Aday öğeleri 1-2 gün önceden paylaşın, böylece geliştiriciler önceden yaklaşımları düşünebilir
• Backlog ile değil, Sprint Goal ile başlayın. Odak sağlar ve kapsam kararlarını kolaylaştırır
• "Nasıl" kısmını geliştiricilere bırakın. Product Owner neyin inşa edileceğini müzakere eder, geliştiriciler nasıl yapılacağına karar verir
• Teknik borç için kapasite ayırın. Deneyimli ekipler sprintlerinin %20'sine kadarını hatalar ve yeniden yapılandırma için ayırır
• Retrospektif aksiyon maddelerini dahil edin. Ekip geçen sprint bir şeyi değiştirmeyi kabul ettiyse, bu sprintin planında yer almalıdır

Sprint planning büyük resimde

Sprint planning bir döngü içindeki bir seremonidir ve diğerleri de üzerlerine düşeni yaptığında en iyi şekilde çalışır. Retrospektifler, bir sonraki sprintin planını besleyen süreç iyileştirmelerini ortaya çıkarır. Sprint review'lar, öncelikleri şekillendiren paydaş geri bildirimlerini ortaya koyar. Günlük stand-up'lar, işler değiştikçe planı uyarlar. Ve backlog rafinasyonu, sprint planning'i verimli kılan hammaddeyi hazırlar. Döngünün geri kalanı sağlıklı olduğunda, sprint planning en kısa toplantı olur, en uzunu değil.