Sprint Review ve Retrospektif Arasındaki Farklar

Giriş

Scrum’da en sık gördüğüm problemlerden biri şu: Sprint’in sonuna gelince ekip “hadi bir toplantı yapalım” diye iki etkinliği birbirine karıştırıyor. Review, retroya; retro da review’a benzemeye başlıyor. Sonuç? Paydaşlar sıkılıyor, ekip geriliyor, aksiyon çıkmıyor, Product Backlog güncellenmiyor… Yani iki toplantı da amacını kaçırıyor.

Oysa Sprint Review ve Sprint Retrospektif, aynı haftaya denk gelse bile bambaşka işler yapar. Biri ürünün ve değer üretiminin nabzını tutar, diğeri takımın çalışma biçimini iyileştirir. İkisini net ayırdığında Scrum “toplantılar bütünü” olmaktan çıkar, öğrenen bir ritme dönüşür.

Aşağıda farkları netleştiriyorum: amaç, katılımcı, gündem, çıktı ve sık yapılan hatalar.

1) Amaç farkı: “Ne ürettik?” vs “Nasıl ürettik?”

Sprint Review’un amacı

Sprint Review, Sprint boyunca ortaya çıkan Increment’ı paydaşlarla birlikte incelemek içindir. Ama sadece “demo yapıp alkış toplamak” değildir. Review’un gerçek amacı şudur:

• Üretilen Increment üzerinden geri bildirim almak
• Pazar, müşteri, iş öncelikleri, riskler gibi yeni bilgileri masaya koymak
• Bu bilgilerle Product Backlog’u uyarlamak

Retrospektifin amacı

Retrospektif ise tamamen farklı bir yere bakar:

• Sprint boyunca nasıl çalıştık?
• Nerede tıkandık, nerede iyi aktık?
• Bir sonraki Sprint’te daha iyi çalışmak için neyi değiştireceğiz?

Kısacası

Review, “Doğru şeyi mi yapıyoruz?” sorusunun evidir. Retro ise “Daha iyi nasıl çalışırız?” sorusunun evidir.

• Review: Ürün ve değer odağı
• Retro: Süreç, iş birliği ve çalışma biçimi odağı

2) Katılımcı farkı: Kitle değişince konuşma değişir

Review’da kimler olur?

Review’un doğasında paydaş vardır. Çünkü amaç, ürünle ilgili geri bildirim almak ve yönü güncellemektir. Dolayısıyla:

• Scrum Team
• Product Owner
• Stakeholder’lar (iş birimleri, kullanıcı temsilcileri, yöneticiler, müşteri tarafı vs.)
• Gerekirse konu uzmanları

Retro’da kimler olur?

Retro ise Scrum Team’in iç etkinliğidir. Çünkü konuşulan şeyler çoğu zaman hassastır: iletişim, çatışmalar, kalite sorunları, baskı, belirsizlik, takım içi dinamikler… Bu konuların sağlıklı konuşulabilmesi için alanın güvenli olması gerekir.

Bu yüzden klasik kural: Retro = Scrum Team (PO dahil, Scrum Master dahil).

Paydaşların retroya katılması, çoğu zaman retro kalitesini düşürür. Ekip, kendini korumaya başlar. Sorunlar yüzeyde kalır.

3) Gündem farkı: Demo ve uyarlama vs öğrenme ve aksiyon

Review tipik akışı

• Sprint hedefi ve bağlam kısaca hatırlatılır
• Increment gösterilir (demo olabilir ama şart değil)
• Geri bildirimler, yeni ihtiyaçlar, değişen koşullar konuşulur
• Product Backlog üzerinde uyarlamalar yapılır
• Sonraki adımlar netleştirilir

Retro tipik akışı

Review’un iyi geçtiğini şu belirler: toplantı sonunda backlog daha net mi, öncelikler daha doğru mu, riskler görünür mü?

Retro’nun iyi geçtiğini şu belirler: toplantı sonunda takımın çalışma biçiminde denenecek somut bir değişiklik var mı?

• Sprint’in nasıl geçtiği konuşulur
• İyi gidenler ve zorlayanlar çıkarılır
• Kök nedenler bulunur
• 1–2 iyileştirme aksiyonu seçilir
• Sahipler ve takip yöntemi belirlenir

4) Çıktı farkı: Backlog güncellemesi vs iyileştirme aksiyonu

Sprint Review çıktısı: Product Backlog’un uyarlanması. Yeni story’ler, öncelik değişimi, çıkarılan işler, risk maddeleri, yeni hedefler…

Retrospektif çıktısı: Süreci iyileştirecek 1–2 aksiyon. Sahibi belli, ölçülebilir veya gözlemlenebilir, Sprint içinde denenecek aksiyonlar…

Biri “ne yapacağız?”ı iyileştirir. Diğeri “nasıl yapacağız?”ı.

5) Sahadan iki kısa hikâye (en sık yaşanan karışıklıklar)

Hikâye 1: Review’un retroya dönmesi

Bir ekipte Review’a paydaşlar geliyor, demo başlıyor. Ama demo bitince takım birden “Sprint boyunca neler kötü gitti”ye giriyor. Deploy sorunları, test eksikleri, kim neyi geciktirdi… Paydaşlar sessizleşiyor. Bir süre sonra toplantı gerilimli bir “hesap verme” alanına dönüyor.

• Paydaş ürünle ilgili geri bildirim veremiyor
• Backlog uyarlanmıyor
• Takım da rahat konuşamıyor çünkü dışarıdan izleyen var

Hikâye 1 için doğru çözüm

Review’da ürün ve backlog konuşulur. Operasyonel/ekip içi meseleler retroya taşınır. Review’da bir konu ekip içi probleme işaret ediyorsa, not alınır ve “Bunu retroda ele alalım” denir.

Hikâye 2: Retro’nun status toplantısına dönüşmesi

Başka bir ekipte retro başlıyor, herkes “şu ticket gecikti, bu iş yetişmedi, şu kişi bekletti” diye ilerliyor. Sonunda aksiyon olarak “daha dikkatli olalım” gibi muğlak bir şey yazılıyor. Bir sonraki Sprint aynı şey tekrar yaşanıyor.

Burada sorun, retro’nun “takımı geliştirme” hedefini kaçırması. Retro bir “raporlama” toplantısı değil. “Bu tekrar etmesin diye neyi değiştireceğiz?” sorusuyla bitmeli.

6) İkisini karıştırmamak için pratik kurallar

Ek bir pratik: Review’da ekip içi bir problem açılırsa, Scrum Master şu cümleyi kullanabilir: “Bunu not alıyorum. Bu retro konusu; orada daha rahat ve derin konuşalım.”

Bu cümle toplantıyı kurtarır.

• Review’da kişiler değil ürün konuşulur. Ürün/Increment → geri bildirim → backlog uyarlama.
• Retro’da ürün değil çalışma biçimi konuşulur. Süreç/iş birliği/kalite → kök neden → 1–2 aksiyon.

Son söz

Sprint Review ve Retrospektif’i ayırmak “Scrum kuralı” olduğu için değil, pratikte hayatı kolaylaştırdığı için önemlidir. Review doğru yapılınca ürün yönü netleşir. Retro doğru yapılınca takımın çalışma biçimi gelişir. İkisi birlikte, Sprint’i sadece bitirmek yerine her Sprint’te daha iyi hale gelmenizi sağlar.

İstersen bir sonraki adımda bunu sayfada kartlı göstermek için kısa bir “Karşılaştırma” metni de yazabilirim: Amaç / Katılımcı / Çıktı / Sık hata / Doğru yaklaşım gibi. Bu, kullanıcıların hızlı taraması için çok iyi oluyor.