Gönderiler

Paydaşların gerçekten katılmak istediği sprint incelemeleri nasıl yapılır

Çoğu sprint incelemesi aynı senaryoyu izler: takım tamamlanan biletlerin listesini gözden geçirir, paydaşlar kibarca başlarını sallar, birisi "iyi görünüyor" der ve herkes ayrılır. Gerçek geri bildirim yok. Rotada değişiklik yok. Sadece takvim slotunu dolduran bir seremoni. Sprint incelemesi, paydaşların ürünün yönünü şekillendirdiği yer olmalı. İşe yaradığında, takımlar doğru şeyi inşa eder. İşe yaramadığında ise, gönderdikleri şeyi kimsenin istemediğini aylar sonra öğrenirler. İşte bunu nasıl düzelteceğiniz.

Demo demekten vazgeçin

Sprint incelemeleri hakkındaki en büyük yanlış anlama, bunların ürün demoları olduğudur. Demo tek yönlüdür: takım gösterir, izleyici izler. Sprint incelemesi, ürünün nereye gittiği hakkında iki yönlü bir konuşmadır. Demo, incelemenin bir parçasıdır, ancak tamamı değildir. Sağlam bir sprint incelemesi ayrıca şunları da kapsar:

• Son sprintten bu yana pazarda, müşterilerde veya yol haritasında ne değişti
• Takımın ürün hedefine doğru yolda olup olmadığı ve verilerin ne söylediği
• Paydaşların az önce gördüklerine dayanarak bundan sonra ne inşa edileceği

Takımlar bu konuşmaları atladığında ve yalnızca tamamlanan işi gösterdiğinde, paydaşların katılım göstermek için hiçbir nedeni kalmaz. E-postayla alabilecekleri bir sunumu izliyorlar.

Paydaşlar neden gelmeyi bırakıyor

Formatı düzeltmeden önce, insanları neyin uzaklaştırdığını anlamak yardımcı olur:

Sorun	Ne olur
Görünür etki yok	Paydaşlar geçen sefer geri bildirim verdi ve hiçbir şey değişmedi
Fazla detaylı	Kimsenin sormadığı küçük arayüz iyileştirmeleri ve hata düzeltmeleri için 45 dakika
Cuma öğleden sonra slot	Hafta sonu yorgunluğu ve erken ayrılmalarla rekabet
Pasif format	Soru sorma veya bir şeyler deneme fırsatı yok
Bağlam yok	Özellikler neden önemli oldukları veya kimlere yönelik oldukları açıklanmadan gösteriliyor

Katılımı öldüren en büyük tek şey birincisidir. Paydaşlar geri bildirimlerinin dikkate alındığını görürlerse geri gelirler. Görmezlerse gelmezler.

İşe yarayan bir sprint incelemesi gündemi

İki haftalık bir sprint için yaklaşık 90 dakika planlayın. İşte paydaşları meşgul tutan bir format.

1. Sahneyi hazırlayın (5 dk)

   Hızlı bir karşılama, herkese ürün hedefini ve bu sprintin amacını hatırlatın. Yeni yüzler varsa, kısa tanıtımlar yapın. Slayt yok.

2. İş bağlamını paylaşın (10 dk)

   Ürün Sahibi, son incelemeden bu yana değişenleri kapsar: müşteri geri bildirimi, pazar değişimleri, hareket eden metrikler. Bu, paydaşların görmek üzere oldukları şey hakkında faydalı geri bildirim verebilmeleri için ihtiyaç duydukları bağlamdır.

3. Çalışan yazılımı gösterin (40-50 dk)

   Artışı gösterin. Yalnızca Tamamlanma Tanımınızı karşılayan bitmiş işi gösterin. Her özellikten sonra durun ve paydaşlara belirli sorular sorun. Bir öğeden diğerine acele etmeyin.

4. Geri bildirim toplayın ve sonraki adımları tartışın (20-25 dk)

   Gösterilenler hakkında açık tartışma. Ne değişmeli? Ne eksik? Takımın bundan sonra neye odaklanması gerekiyor? Paydaşların girdilerinin kaydedildiğini bilmeleri için her şeyi görünür şekilde kaydedin.

5. İleriye bakın (5 dk)

   Sonraki sprint için planlananlara kısa bir ön bakış. Bugünkü konuşma göz önüne alındığında önceliklerin hala doğru hissedilip hissedilmediğini sorun. Bir sonraki inceleme tarihini duyurun.

"Tamamlanan her hikayeyi sun" bloğu olmadığına dikkat edin. Her bileti hesaba katmanıza gerek yok. Paydaş girdisine ihtiyaç duyan öğeleri seçin ve gerisini atlayın.

Demo kısmını gerçekten faydalı hale getirmek

Çoğu inceleme demo sırasında yanlış gider, bu yüzden neyin işe yaradığı konusunda spesifik olmaya değer. Paydaşların yönetmesine izin verin. Senaryolu bir gösterimi ekran paylaşımı yapmak yerine, kontrolü onlara verin. Ürünü ellerine verin, ister bir hazırlık URL'si, bir prototip, ister cihazlarındaki canlı bir uygulama olsun. İnsanlar bir şeyi başkasının tıklamasını izlemektense ilk elden deneyimlediklerinde daha iyi geri bildirim verirler. "Herhangi bir geri bildirim?" yerine belirli sorular sorun. Genel sorular genel yanıtlar alır. Bunun yerine deneyin:

• "Takımınız bunu günlük olarak mı yoksa sadece planlama sırasında mı kullanır?"
• "İş akışınız için faydalı olmadan önce eksik bir şey var mı?"
• "Bunun hakkında bir şeyi değiştirebilseydiniz, ne olurdu?"

Kıdemli paydaşlarla başlayın. Eğer bir VP ilk konuşursa, diğerleri takip eder. Sessizce otururlarsa, diğer herkes de geri durmaya eğilimlidir. Erken soruları en ağırlıklı geri bildirimi olan kişilere yöneltin. Önemsiz şeyleri atlayın. Bir paydaş özellikle istemediği sürece hata düzeltmelerini, küçük stil değişikliklerini veya arka uç yeniden düzenlemelerini göstermeyin. Kırk dakikalık kademeli cilalamayı göstermek, bu sprintte anlamlı bir şey olmadığının sinyalini verir.

Paydaşları geri getiren geri bildirim döngüsü

İnceleme sırasında geri bildirim almak işin sadece yarısıdır. Onunla ne yaptığınız, paydaşların bir dahaki sefere gelip gelmeyeceğini belirler. Bir sprint içinde geri bildirimlere göre hareket edin. Bu yapabileceğiniz en etkili şeydir. Paydaşların girdilerinin inşa edilenleri değiştirdiğini görmeleri gerekir. Her şey olmak zorunda değil. Geçen incelemenin geri bildirimine dayanan görünür bir değişiklik bile güven oluşturur. Sonraki incelemeyi neyin değiştiğiyle açın. Takımın önceki incelemeden gelen geri bildirimlere nasıl yanıt verdiğini göstererek başlayın. "Geçen sefer X'den bahsettiniz. İşte bu konuda ne yaptık." Bu döngüyü kapatır ve incelemelere gelmenin zamanlarına değdiğini kanıtlar. Anında önceliklere taahhütte bulunmayın. Geri bildirimi yakalayın, ardından daha sonra backlog iyileştirmede iyileştirin ve önceliklendirin. Paydaşlar duyulduklarını hissetmek isterler, gerçek zamanlı zamanlama kararları vermek değil.

Uzaktan sprint incelemeleri

Dağıtık takımlar, incelemeleri etkileşimli tutmakta ekstra zorluklarla karşılaşır. Birkaç ayarlama yardımcı olur. Gündem ve bağlamı önceden paylaşın. Soğuk gelen uzak katılımcıların tüm süre boyunca sessiz kalma olasılığı daha yüksektir. Sprint hedefini, tartışılacak ana öğeleri ve girdiye ihtiyaç duyduğunuz kararları en az bir gün önce gönderin. Geri bildirim için ayrı odalar kullanın. Demodan sonra, belirli özellikleri tartışmak için 3-4 kişilik küçük gruplara ayrılın. Büyük video aramaları katılımı bastırır. Küçük gruplar insanların konuşmasını kolaylaştırır. Ürünü toplantıdan önce ellerine verin. Paydaşların kendi başlarına keşfedebilmeleri için önceden bir hazırlık bağlantısı veya test yapısı paylaşın. İnceleme, ilk bakış gösterimi yerine buldukları şey hakkında bir konuşmaya dönüşür. Girdi için yapılandırılmış formatlar kullanın. Sohbet anketleri, Menti anketleri veya sohbetteki basit bir "bu özelliği 1-10 arası değerlendirin", içe dönüklere ve geç katılanlara sessizliği açmadan katkıda bulunma yolu verir.

Çoklu takım ürünleri için bilim fuarı formatı

Birden fazla takım bir ürüne katkıda bulunduğunda, sıralı demolar dayanılmaz hale gelir. Kimse etkileşimde bulunmadıkları takımlardan iki saatlik sunumları izlemek istemez. Bilim fuarı formatı bunu düzeltir. Ürün Sahibinden kısa bir genel başlangıçtan sonra (vizyon ve yol haritası üzerine 10 dakika), her takım bir "stand" kurar, ister bir ayrı oda ister fiziksel bir istasyon olsun. Paydaşlar kendileriyle ilgili standlar arasında dolaşır. Bu, paydaşlara zamanları üzerinde kontrol verir. Özelliklerini inşa eden takımla 15 dakika geçirirler, umursamadıklarını atlarlar ve zamanlarına saygı gösterildiğini hissederek ayrılırlar. Takımlar, uzun bir toplantının sonundaki acele sorular yerine daha derin, daha odaklı geri bildirim alır.

Ürün Sahibinin yapması (ve yapmaması) gerekenler

Ürün Sahibi sprint incelemesini yönetir, ancak bunu nasıl yönettiği toplantıyı yapar ya da bozar. Yapın:

• Bir gündem hazırlayın ve önceden paylaşın
• Takımın inşa ettiğini çerçeveleyen iş bağlamı sağlayın
• Her şeyi kendiniz sunmak yerine tartışmayı kolaylaştırın
• Geliştiricilerin kendi işlerini göstermesine izin verin
• Geri bildirimi yakalayın ve takip edin

Yapmayın:

• Demoyu takımın yerine sizin başarınız olarak sunmayın
• Anında geri bildirimi kabul edin veya reddedin. Toplayın ve daha sonra değerlendirin
• İncelemeyi resmi bir onay veya kabul kapısı olarak kullanmayın
• Sprint hedefi tam olarak karşılanmadığında incelemeyi atlayın. Paydaş girdisine en çok ihtiyaç duyduğunuz zaman işte o zamandır

Son nokta önemlidir. Zor bir sprintten sonra incelemeleri iptal eden takımlar, scrum'ı çalıştıran şeffaflığı kaybeder. Eksik kalan bir sprint yine de incelemeye değerdir ve paydaşlar ne olduğu konusundaki dürüstlüğe saygı duyar.

İncelemelerinizin işe yarayıp yaramadığını ölçmek

Bir metrik panosuna ihtiyacınız yok, ancak birkaç sinyale dikkat edin:

• Katılım eğilimi. Aynı paydaşlar mı geliyor yoksa insanları mı kaybediyorsunuz?
• Geri bildirim kalitesi. Spesifik girdi mi alıyorsunuz yoksa sadece "iyi görünüyor" mü?
• İncelemelerden sonra backlog değişiklikleri. İnceleme, takımın bundan sonra inşa ettiğini değiştirdi mi?
• Geri bildirim takibi. Son incelemenin geri bildiriminin ne kadarı sonraki sprintlere yansıdı?

Katılım sabit, geri bildirim spesifik ve backlog duyduklarınıza göre uyum sağlıyorsa, incelemeleriniz işe yarıyor. Bunlardan herhangi biri düşükse, formatı yeniden gözden geçirin.

Sprint incelemesi vs. retrospektif

Bu iki scrum seremonisi arka arkaya gerçekleşir ve takımlar bazen aralarındaki çizgiyi bulanıklaştırır.

	Sprint incelemesi	Retrospektif
Amaç	Ürünü inceleyin ve planı uyarlayın	Süreci inceleyin ve takımın nasıl çalıştığını uyarlayın
Kim katılır	Scrum takımı + paydaşlar	Yalnızca scrum takımı
Odak	Ne inşa edildi ve bundan sonra ne inşa edilecek	Birlikte nasıl daha iyi çalışılır
Çıktı	Güncellenmiş ürün backlog'u	Süreç iyileştirme için aksiyon öğeleri

İnceleme dışa bakar (ürün ve paydaşlar). Retrospektif içe bakar (takım ve süreç). Her ikisi de önemlidir ve biri diğerinin yerini tutmaz.