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

Bir sonraki sprintleri için iş öğelerini seçen, yapışkan notlar ve görünen bir sprint hedefi ile bir tahta etrafında toplanan çevik ekip 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.

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. Backlog ile değil, buradan başlayın. Hedef, diğer her şeye yön verir.

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ı alın, ardından bilinen kapasite değişikliklerine göre ayarlayın.

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.

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.

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:

Hikaye yazma atölyelerinden sonra, 20-50 yeni öğenin boyutlandırılması gerektiğinde
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.

Bir planning poker oturumunda tahminleme kartlarını aynı anda kaldıran ekip üyeleri, sayılar görünür durumda

Sprint planning'i raydan çıkaran hatalar

Bunlara dikkat edin

Bu kalıplar sprint planning'i herkesin korktuğu toplantıya dönüştürür.

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.

Scrum master, ekip üyeleri izlerken her seremoni için renkli bloklarla iki haftalık bir sprint zaman çizelgesini bir tahtada haritalandırıyor

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

Hızlı kontrol

Sprint planning sırasında ikiden fazla kişi konuşuyor ve geri kalanı sessizse, bir şeyler yanlıştır. Toplantı bir sunum değil, bir konuşma olmalı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.

Backlog rafinasyonu öğeleri hazırlama sürecidir: kabul kriterleri yazma, tahminleme ve kapsamı netleştirme. Sprint planning ise rafine edilmiş öğelerden hangilerine taahhüt edileceğini seçme ve onları nasıl teslim edeceğini planlama sürecidir. Rafinasyon, planlamayı besler.

Bu neredeyse her zaman backlog'un önceden yeterince rafine edilmediği anlamına gelir. Sprint boyunca rafinasyon oturumlarına daha fazla zaman yatırın ve planlama süresinin düştüğünü göreceksiniz. Zaman sınırını uzatmayın. Kök nedeni çözün.

Hayır. Backlog rafinasyonu sırasında tahminleme yapın, böylece Product Owner tahminlere göre öncelikleri ayarlayabilir. Sprint planning'e gelindiğinde, en üstteki öğelerin zaten tahminleri ekli olmalıdır.

Evet. Sprint Backlog için paylaşımlı bir tahta kullanın, Kollabe'nin planning poker'ı gibi araçlarla tahminlemeyi asenkron olarak yapın ve senkron toplantıyı hedef belirleme ve kapsam müzakeresine odaklayın.

09/02/2026 tarihinde son güncelleme