Sprint Review ve Sprint Retrospective: Ürünü ve Süreci Inspect Etmek
Sprint Review bir demo değil, stakeholder'larla Increment'i inspect edip Product Backlog'u adapt eden bir çalışma oturumudur; Retrospective ise bireyleri, süreçleri, araçları ve Definition of Done'ı inspect edip ölçülebilir bir iyileştirmeyi Sprint Backlog'a koyar. Yazı Bookstore'un 90 dakikalık Review gündemini, retro formatlarını ve code review beklemesini 2,1 günden 0,6 güne indiren bir aksiyonu anlatıyor.
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'un Sprint 9 Review'ı: Selin projeksiyonda sekiz slayt gösteriyor, Zeynep iade ekranının ekran kaydını oynatıyor, satış müdürü "güzel olmuş" diyor, toplantı 40 dakikada bitiyor ve kimse Product Backlog'a bakmıyor. Ertesi gün Retrospective'te ekip aynı üç şikâyeti üçüncü kez konuşuyor: code review çok bekliyor, staging sık düşüyor, toplantı çok. Aksiyon olarak "daha dikkatli olalım" yazılıyor.
Bu iki event'ten hangisi Guide'ın tanımına daha uzak? Ve Review'ın sonunda ne değişmiş olmalıydı? Tahminini yaz; iki event'in amacına baktığımızda cevap netleşecek.
Sprint Review: Demo Değil, Çalışma Oturumu
Guide Sprint Review'ın amacını Sprint'in sonucunu inspect etmek ve gelecekteki adaptation'ları belirlemek olarak koyuyor. Scrum Team çalışmasının sonuçlarını kilit stakeholder'lara sunar ve Product Goal'e doğru ilerleme konuşulur. Event boyunca Scrum Team ve stakeholder'lar Sprint'te neyin başarıldığını ve ortamlarında neyin değiştiğini birlikte gözden geçirir; bu bilgiye dayanarak katılanlar sırada ne yapılacağı üzerinde birlikte çalışır. Product Backlog yeni fırsatlara göre ayarlanabilir.
Guide'ın bu bölümdeki en net cümlesi: Sprint Review bir çalışma oturumudur ve Scrum Team onu bir sunumla sınırlamaktan kaçınmalıdır. Bookstore'un Sprint 9 Review'ı tam olarak bir sunumdu. Stakeholder'lar izledi, beğendi ve gitti; ne Increment'i kendileri denedi ne de ortamdaki değişikliği anlattı. Inspection yapılmadı, dolayısıyla adaptation da yok.
Review Sprint'in sondan ikinci event'i; bir aylık Sprint için en fazla dört saatle sınırlı, daha kısa Sprint'lerde genellikle daha kısa. Bookstore iki haftalık Sprint için 90 dakika ayırıyor.
Bookstore'un Review Gündemi
Ekip Sprint 10'dan itibaren Review'ı şöyle kurguladı:
| Süre | Ne oluyor | Kim yönlendiriyor |
|---|---|---|
| 10 dk | Sprint Goal neydi, tuttu mu; neyin Done olduğu, neyin olmadığı ve neden | Developers |
| 30 dk | Stakeholder'lar staging'de iade akışını kendi elleriyle dener; Developers yanında not alır | Stakeholder'lar |
| 20 dk | Ortamda ne değişti: destek ekibinin verisi, kargo firmasının yeni kuralı, rakip | Selin ve stakeholder'lar |
| 30 dk | Product Backlog'un üst kısmı birlikte yeniden konuşulur; Product Goal'e ne kadar yaklaştık | Selin |
İkinci satır en çok şey değiştiren oldu. Destek ekibinden Elif iade formunu doldururken sipariş numarasını bilmeyen müşterinin ne yapacağını sordu; form yalnızca sipariş numarasıyla açılıyordu. Bu soru slaytlarda hiç çıkmamıştı. Üçüncü satırda Elif bir sayı getirdi: iade akışının ilk sürümü yayına çıktığından beri iade için gelen destek e-postası haftada 120'den 85'e inmişti. Product Goal'deki hedef 20'nin altıydı; yol var ama yön doğru.
Dördüncü satırda Product Backlog değişti: "Sipariş geçmişinden iade başlat" item'ı üçüncü sıraya çıktı, "İade durumu için e-posta bildirimi" daha da aşağı indi çünkü Elif'in verisine göre müşteriler panelden takip ediyordu. Review'ın çıktısı bir alkış değil, değişmiş bir Product Backlog'du.
Review'da Ne Gösterilir, Ne Gösterilmez?
Bir önceki yazıdaki kural burada geçerli: Definition of Done'ı karşılamayan item Review'da sunulamaz. Bu kuralın amacı stakeholder'ları kandırmamak; "neredeyse bitti" denen bir ekranı gören satış müdürü onu bitmiş sayıp müşteriye söz verebilir. Bookstore'da Done olmayan item'lar gösterilmiyor ama gündemin ilk satırında neden Done olmadıkları açıkça söyleniyor.
İkinci kural: Review bir onay ya da imza toplantısı değil. Guide Increment'in Sprint bitmeden release edilebileceğini ve Review'ın değeri release etmek için bir kapı olmaması gerektiğini söylüyor. Stakeholder'ın Review'da "onaylıyorum" demesini beklemek, release'i iki haftada bir yapılan bir törene bağlar. Bookstore'da Review'a gelen işin çoğu zaten production'da; stakeholder onun üzerinden konuşuyor.
Sprint Retrospective: Sürecin Inspect Edilmesi
Retrospective'in amacı Guide'da kaliteyi ve etkinliği artırmanın yollarını planlamak. Scrum Team son Sprint'i bireyler, etkileşimler, süreçler, araçlar ve Definition of Done açısından inspect eder. Ekibi yanlış yöne götüren varsayımlar belirlenir ve kökenleri araştırılır. Sprint'te neyin iyi gittiği, hangi problemlerle karşılaşıldığı ve bunların nasıl çözüldüğü ya da çözülemediği konuşulur.
Ardından ekip etkinliğini artıracak en faydalı değişiklikleri belirler. Guide'ın ifadesiyle en etkili iyileştirmeler mümkün olan en kısa sürede ele alınır; bir sonraki Sprint'in Sprint Backlog'una bile eklenebilir. 2017 Guide'ı burada daha kuralcıydı: Sprint Backlog önceki Retrospective'te belirlenmiş en az bir yüksek öncelikli iyileştirmeyi içermeliydi. 2020 sürümü bu zorunluluğu yumuşattı ama niyeti korudu: iyileştirme ayrı bir "süreç listesi"nde değil, ekibin gerçek iş planında yer almalı.
Retrospective Sprint'i bitirir ve bir aylık Sprint için en fazla üç saatle sınırlıdır; daha kısa Sprint'lerde genellikle daha kısadır. Bookstore iki haftalık Sprint için 75 dakika ayırıyor.
Retro Formatları
Guide format vermiyor. Sahada en çok kullanılan üçü ve Bookstore'un hangisini ne zaman seçtiği:
| Format | Nasıl işler | Ne zaman iyi |
|---|---|---|
| Start / Stop / Continue | Başlamamız, bırakmamız ve sürdürmemiz gereken davranışlar ayrı ayrı toplanır | Kısa Sprint'lerde, hızlı ve somut aksiyon gerektiğinde |
| 4L | Liked, Learned, Lacked, Longed for: beğenilen, öğrenilen, eksik kalan, özlenen | Öğrenme yoğun bir Sprint'ten sonra, örneğin yeni bir entegrasyonla uğraşıldığında |
| Timeline | Sprint'in günleri bir çizgiye dökülür, herkes Sprint'te yaşananları ve o andaki hissini işaretler | Zor geçmiş bir Sprint'ten sonra; ekip neyin ne zaman bozulduğunu birlikte görür |
Format seçiminden daha önemli olan, oturumun bir yapısının olması. Esther Derby ve Diana Larsen'in "Agile Retrospectives: Making Good Teams Great" (2006) kitabındaki beş aşama hâlâ en kullanışlı iskelet: ortamı hazırla, veri topla, içgörü üret, ne yapacağına karar ver, kapat. Şikâyet seanslarının çoğu ikinci aşamada takılıp kalıyor; veri toplanıyor ama ondan bir içgörü ve karar çıkmıyor.
Bir Aksiyonun Sprint Backlog'a Girmesi
Sprint 9'un Retrospective'inde ekip timeline formatını kullandı. Çizgide aynı şey üç kez görünüyordu: pull request'ler code review'da ortalama iki gün bekliyordu ve bu sürede yazarı başka bir işe başlıyordu. Önceki Retrospective'te bunun için yazılan aksiyon "daha dikkatli olalım"dı; ölçülemez, sahibi yok, ne zaman biteceği belli değil.
Bu sefer aksiyon şöyle yazıldı: "Açılan pull request aynı iş günü içinde ilk review'ı alır; Daily Scrum board'u sağdan sola yürürken önce Code Review kolonuna bakılır. Sahibi: Emre. Ölçüm: Sprint sonunda pull request'in ilk review'a kadar geçen ortalama süresi." Item Sprint 10'un Sprint Backlog'una, Sprint Goal'ün yanına girdi. Sprint 10'un sonunda ortalama bekleme 2,1 günden 0,6 güne inmişti; ekip bunu Sprint 10 Retrospective'inin ilk beş dakikasında inspect etti ve aksiyonu kalıcı bir çalışma anlaşmasına çevirdi.
İyi bir Retrospective aksiyonunun üç özelliği bu örnekte görünüyor: küçük (bir Sprint'te denenebilir), sahibi belli ve sonucu ölçülebilir. Retrospective'in Definition of Done'ı da inspect ettiğini unutma; Bookstore'un Definition of Done'ındaki OpenAPI maddesi de bir Retrospective aksiyonuydu.
Üretimde Dikkat
Review'ın sağlığı için Bookstore'un baktığı iki sayı: kilit stakeholder'ların kaçı geldi ve Review sonunda Product Backlog'da kaç değişiklik oldu? Üst üste iki Review'da backlog hiç değişmemişse ya ürün mükemmel gidiyor ya da Review bir sunuma dönmüş. İkincisi daha olası.
Retrospective için: aksiyonların kaçı bir sonraki Sprint'te gerçekten uygulandı ve aynı konu kaç Retrospective'te tekrar etti? Aynı şikâyetin üçüncü kez gelmesi, Retrospective'in değil önceki aksiyonların başarısız olduğunu gösterir; bazen de sorunun ekibin değiştirebileceği alanın dışında olduğunu. O zaman konu Scrum Master'ın kuruma hizmetine geçer.
Ölçekte, aynı ürün üzerinde birden çok ekip varsa tek bir ortak Review çoğu zaman en iyisi; stakeholder entegre Increment'i görür, ekipler arası bağımlılıklar da görünür olur. Retrospective'ler ise önce ekip içinde, sonra ekipler arası bir oturumla yapılabilir; Nexus bunu kendi event'leriyle tanımlıyor.
Sık Düşülen Tuzaklar
Review'ın onay ya da imza toplantısına dönmesi. Stakeholder'ın rolü onaylamak değil, inspect etmek ve sırada ne olacağına katkı vermek. İmza bekleyen bir Review release'i iki haftalık bir törene bağlar.
Review'ı yalnız Product Owner'ın sunduğu bir slayt gösterisine çevirmek. Guide Scrum Team'in sonuçları sunduğunu ve oturumun bir çalışma oturumu olduğunu söylüyor; slaytlar bunun yerine geçmez.
Retrospective'in şikâyet seansı olup aksiyon üretmemesi. Veri toplanıyor, herkes rahatlıyor, ama Sprint Backlog'a hiçbir şey girmiyor. Bir sonraki Sprint aynı problemlerle başlıyor.
Retrospective'e yöneticinin katılması ve güvenin kaybolması. Guide Retrospective'i Scrum Team'in event'i olarak tanımlıyor; ekibin gerçek problemleri konuşamadığı bir ortamda inspection da yüzeysel kalır.
Her Sprint aynı formatı kullanmak. Ekip bir süre sonra cevapları ezberler; format değiştirmek aynı Sprint'e farklı bir açıdan bakmayı sağlar.
Küçük Bir Deneme
★☆☆ Son Review'ınızın sonunda Product Backlog'da neyin değiştiğini yaz. Hiçbir şey değişmediyse bir sonraki Review'a stakeholder'ların kendi elleriyle Increment'i denediği 20 dakikalık bir bölüm ekle.
★★☆ Son üç Retrospective'in aksiyonlarını listele ve her birinin yanına sahibini, ölçümünü ve bir sonraki Sprint'te uygulanıp uygulanmadığını yaz. Bu üç bilgiden biri eksik olan aksiyonları yeniden yaz.
★★★ Bir sonraki Retrospective'i Derby ve Larsen'in beş aşamasıyla planla; her aşamaya bir aktivite ve süre ver. Oturumdan sonra hangi aşamanın en çok zaman aldığını ve aksiyonun hangi aşamada netleştiğini not et.
Blok A burada bitiyor: Guide'ın bütün accountability, event, artifact ve commitment'larını gördük. Bir sonraki yazıyla sahaya iniyoruz: velocity, burndown ve Sprint Goal başarısı gibi metrikler gerçekte neyi gösteriyor, neyi gizliyor ve Goodhart yasası bir ekibe nasıl zarar veriyor?