Scrum Seremonilerinde UX: Hangisine Katılmaya Değer

UX'in Scrum seremonilerine katılması gerektiğini her kaynak yazıyor, hangisinden vazgeçilebileceğini yazan yok. İki haftalık bir sprintte beş seremoninin toplamı yaklaşık yedi buçuk saat tutuyor ve üç takımla çalışan bir tasarımcı için bu, kapasitenin dörtte birinden fazlası demek. Toplantıları sıralamak gerekiyor.

Yükü önce sayın

İki haftalık sprint, tek takım, tipik süreler: günlük toplantı 15 dakika × 10 iş günü, yani 150 dakika. Backlog iyileştirme 60, sprint planlama 120, demo 60, retrospektif 60 dakika. Toplam 450 dakika, yani 7,5 saat. 80 saatlik bir sprintte yüzde 9.

Tek takımda bu rakam tartışmaya değmez. İki takımda 15 saat, üçte 22,5 saat; Figma açılmadan kapasitenin yüzde 28'i gitmiş olur. Burada "hepsine katıl ve daha hızlı çalış" cevabı işlemiyor, çünkü toplantı süreleri sizin verimliliğinizle kısalmıyor. Kesilecek bir şey var.

Backlog iyileştirme: vazgeçmeyeceğiniz toplantı

Bir işin şekli burada donuyor. Kabul kriterleri yazıldıktan ve tahmin verildikten sonra o şekli değiştirmek, yeniden planlama ve çoğu zaman yeniden geliştirme demek.

"Kullanıcı filtrelerini kaydedebilir" satırını düşünün. Kayıt kişiye mi özel, tüm takıma mı açık? Varsayılan bir filtre olacak mı? Kaydedilmiş filtre, listedeki sütun yapısı değiştiğinde ne yapıyor? Bu üç soruyu iyileştirme toplantısında sormak bir dakika alır. Sormazsanız cevapları geliştirici verir, çünkü kod yazmak için bir cevaba ihtiyacı var ve en yakındaki makul varsayımla ilerler. Aynı soruyu demoda sormak bir sprint geri alır.

Planlama: sorun görünürlük değil, önden gitmek

Tasarım ve araştırma işlerinin sprint backlog'unda kalem olarak görünmesi doğru, ama tek başına bir şeyi çözmüyor. Araştırması yapılmamış bir iş planlamaya girdiğinde iki seçenek kalıyor: işi bilinmezle başlatmak, ya da aynı iki hafta içinde araştırıp tasarlayıp geliştirmeye çalışmak. İkincisi nadiren oturuyor.

Çalışan düzen şu: araştırma ve tasarım bir sprint önden gider, geliştirme bir sonraki sprintte onu alır. Buna "şelaleye dönüyoruz" diyen çıkar. Dönmüyorsunuz, boru hattı kuruyorsunuz. Şelalede geri bildirim tek yönlü akar; bu düzende her sprintte test sonucu geri geliyor ve önde giden tasarımı değiştiriyor.

Demo: tasarımı değil, kullanıcının yaptığını gösterin

Paydaşlara ekran göstermeyi ürün sahibi de yapabilir. UX'in demoya kattığı şey, o ekranla karşılaşan beş kişinin nerede durakladığı. Tek cümlelik bir not bile toplantının yönünü "güzel olmuş"tan "burayı değiştirelim"e çeviriyor.

Günlük toplantı: kesilecek yer burası

Beş seremoninin en büyük bloğu günlük toplantı. 150 dakika, toplamın üçte biri. Tek takımda kalıyorsanız sorun değil. Üç takımla çalışıyorsanız haftada iki güne indirip kalan günleri yazılı not bırakarak geçmek tasarım kalitesinden hiçbir şey eksiltmiyor. Engelin çıktığı gün ertesi sabahı beklemeyin, o anda söyleyin; standup'ın engel bildirme işlevi zaten pratikte bu yüzden boşa çıkıyor.

Retrospektif neyi taşır, neyi taşımaz

Kullanıcı şikayetlerini retrospektife taşımam. Orası takımın kendi çalışma biçimini konuştuğu yer; kullanıcının yaşadığı sorun backlog'a girer ve diğer işlerle birlikte önceliklendirilir. Retrospektifin konusu süreç tarafı: tasarım işe geç yetişti mi, test katılımcısı bulunamadı mı, kabul kriterleri tasarım görülmeden mi yazıldı. Bunlar bir sonraki sprintte gerçekten düzelebilecek şeyler.

Sıralama

Bir toplantıdan çıkmak zorundaysanız sıra şöyle, vazgeçilmeyenden başlayarak:

1. Backlog iyileştirme
2. Sprint planlama
3. Demo
4. Retrospektif
5. Günlük toplantı

Bu sıra, toplantıda verilen kararın geri alınma maliyetine göre kurulu. İyileştirme toplantısında söylenmeyen şey koda giriyor. Standup'ta söylenmeyen şey ertesi gün söylenebiliyor.