Sprint ve Sprint Planning: Why, What, How ve Sprint Goal
Sprint bir aydan kısa, sabit uzunlukta bir event'tir; Sprint Planning ise why, what ve how sorularıyla Sprint Goal'ü ve Sprint Backlog'u üretir. Developers seçilen item listesine değil Sprint Goal'e commit olur; liste bir forecast'tir. Yazı iyi ve kötü Sprint Goal örneklerini, iptal yetkisinin neden yalnız Product Owner'da olduğunu ve Bookstore ekibinin brüt kapasitenin yüzde 72'sine inen gerçek kapasite hesabını gösteriyor.
Sürüm notu: Bu yazı Scrum Guide 2020'yi (Kasım 2020, Ken Schwaber ve Jeff Sutherland) esas alır; Kasım 2026 itibarıyla scrumguides.org'daki güncel resmi sürüm hâlâ budur. Timebox değerleri Guide'daki gibi bir aylık Sprint içindir.
Önce Tahmin Et
Bookstore ekibi iki haftalık Sprint'le çalışıyor: on iş günü, beş Developer, kâğıt üzerinde 50 kişi-gün. Bu Sprint'te Zeynep iki gün izinli, ekip sırayla production destek nöbeti tutuyor ve nöbetçi zamanının yarısını destek işine veriyor. Bir de Scrum event'leri var: Sprint Planning, her gün Daily Scrum, Sprint Review, Sprint Retrospective ve refinement oturumu.
Sprint Goal'e gerçekten ayrılabilecek süre 50 kişi-günün yüzde kaçıdır: yüzde 90 mı, yüzde 70 mi, yüzde 50 mi? Tahminini yaz; yazının ortasında ekibin gerçek hesabını göreceksin. Bir soru daha: aşağıdaki iki Sprint Goal'den hangisi Guide'ın tanımına uyar? "Sprint 7'deki 12 ticket'ı bitirmek" ve "Kayıtlı bir müşteri teslim edilmiş tek kalemli bir siparişin iade talebini uçtan uca oluşturabilsin ve talep destek panelinde görünsün."
Sprint: Scrum'ın Kalp Atışı
Guide Sprint'leri fikirlerin değere dönüştüğü yer, Scrum'ın kalp atışı olarak tanımlıyor. Sprint'ler tutarlılık yaratmak için sabit uzunlukta, bir ay ya da daha kısa event'lerdir ve bir Sprint biter bitmez yenisi başlar. Product Goal'e ulaşmak için gereken bütün iş, Sprint Planning, Daily Scrum'lar, Sprint Review ve Sprint Retrospective dahil, Sprint'lerin içinde olur. Yani Sprint'ler arasında "ara hafta", "hazırlık haftası" ya da "test haftası" yoktur.
Sprint boyunca dört kural geçerli:
- Sprint Goal'ü tehlikeye atacak değişiklik yapılmaz.
- Kalite düşmez.
- Product Backlog gerektikçe refine edilir.
- Daha çok şey öğrenildikçe kapsam Product Owner'la netleştirilebilir ve yeniden konuşulabilir.
Son iki kural Sprint'in donmuş bir sözleşme olmadığını söylüyor. Kargo firmasının API'sinin (Application Programming Interface) iade etiketini yalnız PDF (Portable Document Format) olarak döndürdüğü üçüncü günde anlaşıldığında, Ayşe ve Selin "etiket ekranda gösterilsin" maddesini "etiket e-postayla gönderilsin" olarak değiştirdi. Sprint Goal (müşteri iade talebini uçtan uca oluşturabilsin) değişmedi; ona giden iş değişti.
Uzunluk seçimi bir trade-off. Guide, ufku çok uzun bir Sprint'te Sprint Goal'ün geçersiz hale gelebileceğini, karmaşıklığın ve riskin artabileceğini söylüyor; daha kısa Sprint'ler daha çok öğrenme döngüsü üretir ve maliyet ile emek riskini daha küçük bir zaman dilimiyle sınırlar. Bookstore iki haftayı seçti: bir haftalık Sprint'te Planning, Review ve Retrospective'in sabit yükü oransal olarak büyüyordu; dört haftada ise stakeholder geri bildirimi ayda bire düşüyordu. Seçim yapıldıktan sonra uzunluk sabit kalıyor; "bu Sprint iki gün uzatalım" seçeneği yok.
Sprint'i Kim İptal Eder?
Guide'a göre Sprint Goal eskirse Sprint iptal edilebilir ve bu yetki yalnızca Product Owner'dadır. Bookstore'da bu bir kez oldu: Sprint'in dördüncü gününde ödeme sağlayıcısı kısmi iade API'sini kapatacağını duyurdu ve Sprint Goal'ün tamamı kısmi iade üzerineydi. Selin Sprint'i iptal etti; ekip aynı gün yeni bir Sprint Planning yaptı.
İptal nadir olmalı ve pahalıdır: yarım kalan iş ya Product Backlog'a döner ya da yeniden değerlendirilir, Planning yeniden yapılır, ekibin ritmi bozulur. 2020 Guide'ı iptal bölümünü önceki sürümlere göre çok kısalttı; geriye tek bir ilke kaldı: Sprint'i ancak hedefi anlamını yitirdiğinde ve yalnız Product Owner iptal eder. Bir müdürün "acil bir iş geldi, Sprint'i durdurun" demesi bu ilkenin dışında. O iş Selin'e gelir; Selin Sprint Goal'ün hâlâ anlamlı olup olmadığına karar verir.
Sprint Planning: Why, What, How
Sprint Planning Sprint'i başlatır ve Sprint'te yapılacak işi ortaya koyar; plan bütün Scrum Team'in ortak işidir. Product Owner katılanların en önemli Product Backlog item'larını ve bunların Product Goal'le ilişkisini konuşmaya hazır gelmesini sağlar. Ekip tavsiye için başka kişileri de davet edebilir; Bookstore'da kargo API'sinin anlaşıldığı Sprint'te muhasebeden bir uzman ilk yarım saate katıldı.
2020 Guide'ı Planning'i üç konuya ayırıyor. 2013'ten beri "what" ve "how" vardı; "why" 2020'de eklendi.
Birinci konu: Bu Sprint neden değerli? Product Owner ürünün bu Sprint'te değerini ve faydasını nasıl artırabileceğini önerir; ardından bütün Scrum Team, Sprint'in stakeholder'lar için neden değerli olduğunu anlatan bir Sprint Goal'ü birlikte tanımlar. Sprint Goal Planning bitmeden kesinleşmelidir.
İkinci konu: Bu Sprint'te ne Done yapılabilir? Developers Product Owner'la konuşarak Product Backlog'dan item seçer; bu sırada item'lar refine edilebilir. Ne kadarının sığacağını seçmek zordur; Guide, Developers geçmiş performanslarını, yaklaşan kapasitelerini ve Definition of Done'larını ne kadar iyi bilirse forecast'lerine o kadar güveneceklerini söylüyor.
Üçüncü konu: Seçilen iş nasıl yapılacak? Developers seçilen her item için Definition of Done'ı karşılayan bir Increment yaratacak işi planlar. Bu genellikle item'ları bir gün ya da daha kısa süren küçük iş parçalarına bölerek yapılır. Nasıl yapılacağı yalnızca Developers'ın takdirindedir.
Sprint Goal, seçilen item'lar ve onları teslim etme planı birlikte Sprint Backlog'u oluşturur. Planning bir aylık Sprint için en fazla sekiz saatle sınırlıdır; daha kısa Sprint'lerde event genellikle daha kısadır. Bookstore'un iki haftalık Planning'i çoğu Sprint'te üç saat sürüyor ve dört saati hiç geçmedi.
Commit Değil Forecast
2010 Guide'ında ekip Sprint Planning'de seçtiği işi tamamlamaya "commit" oluyordu. 2011 revizyonu bunu değiştirdi: Developers Sprint'te biteceğine inandıkları işin bir forecast'ini yapar ve bu forecast Sprint boyunca daha çok şey öğrenildikçe değişir. Sebep sahada görülen davranıştı: seçilen her item'a söz verilmiş gibi bakıldığında ekipler ya az seçiyor ya da kaliteden kısarak "sözü tutuyordu".
2020'de commitment kelimesi geri geldi, ama başka bir yere: Developers seçilen item listesine değil, Sprint Goal'e commit olur. Guide Sprint Goal'ü Sprint'in tek amacı olarak tanımlıyor ve önemli bir esneklik ekliyor: Sprint Goal bir commitment olsa da ona ulaşmak için gereken işin tam olarak ne olduğu konusunda esneklik sağlar. İş beklenenden farklı çıkarsa Developers Product Owner'la birlikte Sprint Goal'ü etkilemeden Sprint Backlog'un kapsamını yeniden konuşur. Yani item listesi bir forecast, Sprint Goal bir commitment.
İyi Sprint Goal, Kötü Sprint Goal
Sprint Goal'ün yazılma biçimi bu esnekliğin var olup olmadığını belirliyor. Bookstore'un ilk üç Sprint'inden örnekler:
| Sprint Goal | Sorun ya da güç |
|---|---|
| Sprint 7'deki 12 ticket'ı bitirmek | Bir hedef değil, bir liste; bir ticket kayınca hedef de kayar ve hiçbir esneklik yok |
| İade backend'ini tamamlamak | Katmanla sınırlı; Sprint sonunda kullanılabilir bir şey çıkmayabilir |
| Kayıtlı bir müşteri teslim edilmiş tek kalemli bir siparişin iade talebini uçtan uca oluşturabilsin ve talep destek panelinde görünsün | Stakeholder için anlamlı, test edilebilir; kargo etiketi ekranda değil e-postada olsa da hedef korunur |
| Kısmi iadenin ödeme sağlayıcısında çalışıp çalışmadığını gerçek bir test iadesiyle öğrenmek | Öğrenme hedefi; Increment küçük olabilir ama riskli bir bilinmezi kapatır |
İyi bir Sprint Goal'ün iki işareti var. Birincisi, ekip bir item'ı çıkarmak zorunda kaldığında "hedef hâlâ tutuyor mu?" sorusunu sorabiliyor. İkincisi, Sprint Review'da stakeholder'a tek cümleyle anlatılabiliyor. Plan anlatmaya çalıştığın şey bir liste ise, elinde muhtemelen bir Sprint Goal değil bir Sprint Backlog özeti var.
Kapasite: Takvim Gerçeği
Baştaki soruya dönelim. Bookstore ekibinin bu Sprint için yaptığı hesap:
| Kalem | Kişi-gün |
|---|---|
| Brüt: 5 Developer × 10 gün | 50,0 |
| Scrum event'leri ve refinement (kişi başı 11,25 saat: Planning 4, Daily 9 × 0,25, Review 2, Retro 1,5, refinement 1,5) | -7,0 |
| Destek nöbeti: her gün bir kişi, zamanının yarısı | -5,0 |
| Zeynep'in izni | -2,0 |
| Sprint Goal'e kalan | 36,0 |
Sonuç brüt kapasitenin yüzde 72'si. Code review, ortam sorunları ve beklenmedik toplantılar bu tabloda yok; yani gerçek oran daha da düşük. Ekip bu yüzden item seçerken saatlere değil, son üç Sprint'te gerçekten Done olan item sayısına bakıyor (sırasıyla 9, 11 ve 10) ve bu Sprint'in daha düşük kapasitesini hesaba katıp 8 item'la başlıyor. Estimation tekniğinin kendisi, story point ya da item sayısı, ilerideki Estimation ve Planning serisinin konusu; Guide yalnızca geçmiş performans, kapasite ve Definition of Done'ın forecast'i besleyeceğini söylüyor.
Üretimde Dikkat
Sprint ve Planning'in sağlığını ölçen en dürüst sayı Sprint Goal'e ulaşma oranı. Seçilen item'ların yüzde kaçının bittiği ikinci planda kalıyor; hedef tutuyorsa birkaç item'ın Product Backlog'a dönmesi normal. Bookstore son altı Sprint'te dört kez Sprint Goal'e ulaştı; ulaşamadığı iki Sprint'te ortak nokta Planning'de kapasite tablosunun yapılmamış olmasıydı. Metriklerin neyi gösterip neyi göstermediği serinin sekizinci yazısının konusu.
Planning'in süresi de bir sinyal. Planning sürekli timebox'ı zorluyorsa sorun genellikle Planning'de değil, refinement'tadır: item'lar Sprint'e girecek kadar küçük ve net değildir ve analiz Planning'in içinde yapılmaya çalışılır.
Ölçekte, aynı ürün üzerinde çalışan birden çok ekip ayrı Planning'ler yapsa bile Sprint'lerini aynı takvime hizalamak bağımlılıkları görünür kılar. Guide bunu zorunlu tutmuyor; Nexus gibi ölçekleme framework'leri bunu tanımlıyor.
Sık Düşülen Tuzaklar
Sprint Goal'ü ticket listesinin özeti yapmak. "Ödeme, iade ve bildirim işlerini bitirmek" bir hedef değil, üç item'ın virgülle birleştirilmesi. Böyle bir hedef ekibi aynı amaca değil, ayrı işlere dağıtır; Guide'ın Sprint Goal için istediği "tutarlılık ve odak" kaybolur.
Kapasite planında toplantı ve destek yükünü unutmak. Brüt kapasiteyle seçilen iş her Sprint taşar ve ekip "estimation yapamıyoruz" sonucuna varır; oysa sorun estimation'da değil, takvimin gerçeğindedir.
Planning'i Product Owner'ın ya da bir yöneticinin iş dağıttığı bir toplantıya çevirmek. "How" Developers'ın takdirindedir; iş parçalarına kimin bakacağı da self-managing ekibin kararıdır.
Sprint'i uzatmak ya da hedef tutmayınca "Sprint 7b" açmak. Sabit uzunluk bilerek konmuş bir kısıt; ritmi korumak, ekibin forecast'ini Sprint'ten Sprint'e karşılaştırılabilir kılar.
Küçük Bir Deneme
★☆☆ Son üç Sprint Goal'ünüzü yaz ve her birini tek cümleyle bir stakeholder'a anlatmayı dene. Anlatmak için item saymak zorunda kaldığın hedefleri işaretle.
★★☆ Bir sonraki Sprint için yukarıdaki gibi bir kapasite tablosu yap: brüt kapasiteden event'leri, destek yükünü ve izinleri düş. Sonra Sprint sonunda gerçek dağılımı aynı tabloya yaz ve farkın en büyük olduğu kalemi bul.
★★★ Bir Sprint boyunca Sprint Backlog'daki değişiklikleri kaydet: eklenen, çıkarılan, bölünen item'lar ve sebepleri. Sprint sonunda hangi değişikliklerin Sprint Goal'ü koruyarak yapıldığını, hangilerinin hedefi değiştirdiğini ayır. İkinci grubun kararını kim verdi?
Sprint başladı ve bir plan var. Bir sonraki yazıda bu planın her gün nasıl inspect edildiğine bakıyoruz: Daily Scrum neden bir status raporu değil, 2020'de üç soru neden kalktı ve board'u sağdan sola yürümek ne işe yarıyor?