Ana sayfa → Bölüm 06
Sprint Review: Demo Şovu Değil, Geri Bildirim Döngüsü
Kimse değişiklik önermiyorsa dinlemiyordur. Sprint review’da alkış iyi bir sinyal değildir; itiraz iyi bir sinyaldir.
- Geri bildirim > alkış. Sessizlik en tehlikeli sinyaldir; ilgisizliğin ya da güven kaybının işaretidir.
- Paydaşı sürecin parçası yap. Sürecin parçası olmayan paydaş, sonucun karşısında olur.
- Cilalı demo yasak. Eksikleriyle birlikte çalışan yazılım göster; provalı gösteri gerçeği saklar.
- Backlog değişmediyse review olmamıştır. Çıktısı revize edilmiş bir backlog’dur.
Nedir, ne değildir
Artımı incelemek, gerçek geri bildirime göre backlog’u uyarlamak ve paydaşı ürünün ortak sahibi haline getirmek için yapılan bir çalışma oturumu.
Cilalı bir demo şovu, yönetime sunulan bir statü raporu veya sprint’i uğurlama kutlaması.
Ayırt etmenin en basit yolu şu: toplantı bittiğinde backlog’da bir şey değişti mi? Değişmediyse yapılan şey bir demoydu.
Neden paydaşı içeri almak zorundasın
Bir paydaş ürünün inşa sürecine dahil edilmezse teslim anında eleştirmen koltuğuna oturur. Bu kötü niyet değil, insan doğası. Ama aynı kişi iki haftada bir çalışan yazılımı görüyor, geri bildirim veriyor ve o geri bildirimin bir sonraki sprint’te hayata geçtiğini izliyorsa artık eleştirmen değil, ortak yapıcıdır.
Bunun bilinen bir karşılığı var: insanlar üretilmesine katkıda bulundukları şeye orantısız değer atfeder. Sprint review bu etkiyi tetikleyen mekanizmadır. Katkı hissi vermek için paydaşın kararı gerçekten etkilemesi gerekir — biçimsel bir “görüşünüz nedir” sorusu bunu üretmez.
Hızlı geri bildirimin üç faydası
- Maliyet. Yanlış kararı iki hafta sonra düzeltmek ucuzdur; iki ay sonra düzeltmek bütçeyi yakar.
- Heyecan. Somut ilerleme gören paydaş desteğe döner. Görmeyeni ikna etmek için sunum hazırlarsın.
- Sorumluluk paylaşımı. Review’da onay veren paydaş teslimatta “ben bunu istememiştim” diyemez.
Önerilen gündem — 60 dakika
| Süre | Bölüm | İçerik |
|---|---|---|
| 5 dk | Bağlam | Sprint hedefi neydi? Hangi iş problemini çözmeye çıktık? |
| 10 dk | Ne teslim edildi | Tamamlananların üst düzey özeti. Demoya dalmadan önce harita. |
| 20 dk | Canlı demo | Çalışan yazılım. Paydaş kendisi tıklasın; demo ortasında soru teşvik edilsin. |
| 15 dk | Geri bildirim | Ne değişmeli, ne eksik? Sessizlik varsa doğrudan soru sor. |
| 10 dk | Backlog çıkarımları | Ne ekleniyor, ne yeniden önceliklendiriliyor, ne çıkarılıyor? |
Son on dakika pazarlık konusu değildir. Atlanan tek bölüm oysa, toplantı yine bir demoya dönüşmüş demektir.
Doğru katılımcılar
Herkesi davet etmek katılımı azaltır. Üç grup yeter:
- Geri bildirim verebilecekler: problem alanını bilen kullanıcılar, alan uzmanları.
- Karar verebilecekler: yön veya öncelik değişikliğini onaylayabilecek kişiler.
- Bilmesi gerekenler: bağımlı ekipler ve ilgili yöneticiler.
Kendi eklediğim kural: davet listesinde “bilmesi gerekenler” grubu diğer ikisinin toplamından kalabalıksa toplantı sunuma dönüşür. Bu durumda onlara ayrı bir özet gönder, review’ı küçük tut.
Gerçek geri bildirim almak
Review’un en zor kısmı burası. Paydaşlar genelde kibar bir onaya sığınır: “güzel olmuş, eline sağlık.” Bu cümle bilgi taşımaz. Kapalı uçlu sormayı bırak:
- “Gördüğünüz şeyde sizi şaşırtan ne oldu?”
- “Bir şeyi değiştirebilseydiniz bu ne olurdu?”
- “Bunu bugün olduğu gibi kullanır mıydınız, yoksa eksik mi?”
- “Bunu daha kullanışlı yapmak için ne gerekiyor?”
- “Gördüklerinize göre sırada ne yapmalıyız?”
Sessizlikle baş etmenin pratik yolu: genel bir soru sorup beklemek yerine belirli bir kişiye belirli bir soru sor. “Ayşe, bu ekranı çağrı merkezi ekibin günde kırk kez açacak — akış sana mantıklı geldi mi?” Adres verilen soru cevapsız kalmaz.
Yaygın hatalar
- Demo tiyatrosu: saatlerce prova, pürüzleri gizleyen senaryolar.
- Paydaş yok: odada sadece ekip var, geri bildirim üretilmiyor.
- Bitmediği için iptal: “hiçbir şey bitmedi, review yapmayalım.”
- Backlog değişmiyor: geri bildirim toplanıyor ama hiçbir şey olmuyor.
- Provasız göster; eksikleri açıkça söyle
- Paydaş gelmiyorsa sebebini araştır — bu bir güven göstergesi
- Devam eden işi göster, erken geri bildirim al
- Her geri bildirimi backlog’a bir maddeye bağla, kararı orada göster
Review etkinliğini ölçmek
| Sinyal | İyi | Kötü |
|---|---|---|
| Paydaş katılımı | Kilit paydaşlar var ve konuşuyor | Boş oda ya da sadece ekip |
| Üretilen geri bildirim | Uygulanabilir birden çok içgörü | Kibar kafa sallama, itiraz yok |
| Backlog değişikliği | Madde eklendi / yeniden sıralandı | Backlog aynı kaldı |
| Paydaş heyecanı | “Bunu ne zaman kullanabiliriz?” | Pasif izleme, erken çıkış |
Kontrol listesi
- Sprint hedefi başta hatırlatıldı mı?
- Çalışan yazılım gösterildi mi (slayt değil)?
- Paydaş ekrana kendisi dokundu mu?
- En az bir kişiye adıyla soru soruldu mu?
- Toplanan geri bildirimler backlog maddesine dönüştü mü?
- Reddedilen geri bildirimlerin gerekçesi söylendi mi?
Sonuç
Sprint review, iki haftada bir geri bildirim döngüsünü kapatma şansındır. Ama asıl gücü geri bildirimde değil, sahiplik yaratmasındadır. Doğru insanları çağır, gerçek işi göster, zor soruları sor ve öğrendiğine göre backlog’u değiştir.
Alternatif, boşlukta inşa etmektir. Boşlukta inşa edilen ürünler gerçeklikle ilk temaslarında çöker.
“Parçası olmazsa karşısında olur” ilkesi, 60 dakikalık gündem ve geri bildirim soruları İbrahim Demir’in Sprint Review yazısından uyarlandı. Katılımcı dengesi kuralı ve “adres verilen soru” tekniği benim eklemem. Marty Cagan’ın Inspired ve Teresa Torres’in Continuous Discovery Habits kitapları devam okuması olarak iyi.