Agile'da UX İşini Görünür Kılmak: Alt Görev, Sütun ve Kabul Kriteri

Sprint planında UX işi çoğu zaman tek bir satıra sıkışır: “tasarım hazır olacak”. İşin nerede durduğu, ne kadar sürdüğü, kimin kimi beklediği görünmez. Kullanıcı hikayesi bunu düzeltmek için iyi bir kap, ama hikayeye alt görev eklemek tek başına yetmiyor. Tahmin birimi ve kabul kriteri de aynı dile çevrilmediği sürece UX işi panoda görünür, planda görünmez kalır.

Alt görev, hikayenin içinde kalmalı

Bir kullanıcı hikayesini parçalarken geliştirici görevlerinin yanına UX görevleri de yazılır: akışın çizilmesi, prototip, kullanılabilirlik testi, varsa kısa bir araştırma turu. Bunları hikayenin altında tutmanın sebebi raporlama değil, zamanlama. UX işini kendi ayrı hikayesine çıkardığınız anda o hikaye bir sprintte, geliştirme hikayesi başka bir sprintte biter; aradaki boşlukta ürünün geri kalanı değişir ve tasarım daha kodlanmadan eskimiş olur.

Bir ekipte tasarım işlerini kendi hikayelerine ayırmıştık, iki sprint sonra tasarımı bitmiş ama hiç geliştirilmemiş on iki hikaye birikmişti.

Alt görev seviyesinde takibin asıl kazancı, geliştiricinin ve ürün sahibinin test oturumuna davet edilebilir hale gelmesidir. Görev panoda bir satır olarak durduğunda ona katılmak mümkün; “tasarım tarafında bir şeyler yapılıyor” denildiğinde değil.

Panoya sütun eklemek sayılı bir iştir

Alt görev kullanamayan ekipler UX aşamalarını panoya sütun olarak ekler. Burada sık yapılan hata sayıyı kontrol etmemek. Tanımlama, tasarım, kullanılabilirlik testi, geliştiriciye hazır, geliştirme, test, canlıya alma: yedi durak. Her durak bir devir teslim demek ve her devir teslimde iş, sırası gelene kadar bekler. İki haftalık bir sprintte on iş günü var; her durakta ortalama yarım gün bekleme olsa yedi durak 3,5 günü sadece bekleyerek harcar. Hikayenin bittiği gün sprintin son günü olur, test bulgusu çıkarsa sığacak yer kalmaz.

Pratikte üç dört sütun yeterli: hazır, yapılıyor, incelemede, bitti. Kullanılabilirlik testi gibi aşamaları sütun yapmak yerine alt görev olarak taşımak, aynı görünürlüğü bekleme süresi üretmeden verir. Sütun sayısını artırmak süreci şeffaflaştırmıyor, her hikayeyi kendi içinde küçük bir şelaleye çeviriyor.

Kabul kriteri neyi ölçtüğünü bilmeli

UX kabul kriteri yazma tavsiyesi doğru, verilen örnekler genelde yanlış. “Kullanıcılar ana işlemi iki dakikada tamamlayabilmelidir” kulağa ölçülebilir geliyor, ama ölçümün nerede yapılacağı belirsiz. Prototipte ölçerseniz gerçek veri yükleme süresi, boş durumlar ve hata mesajları yok; elde ettiğiniz süre canlı ürünün süresi değil. Canlı üründe ölçerseniz hikaye çoktan kapatılmış olur, kriter de kapanmış bir işi geri açmak için kullanılır.

İkinci sorun örneklem. Beş katılımcılı bir oturumda tek bir yavaş katılımcı ortalamayı rahatça eşiğin üstüne taşır. Bir hikaye, ürün bozuk olduğu için değil, o gün o masaya oturan kişi yüzünden reddedilir.

Eşik yerine gözlenebilir koşul yazın:

• Hiçbir katılımcı ödeme adımında geri dönmek zorunda kalmadı.
• Formun boş, yükleniyor ve hata durumları tasarımda tanımlı ve uygulandı.
• Akış klavyeyle baştan sona tamamlanabiliyor.
• Alan doğrulama mesajı, hatalı alanın yanında görünüyor.

Bunlar beş kişiyle de, tek kişiyle de aynı cevabı verir. Süre hedefleri ürün metriği olarak izlenmeye değer, hikaye kapatma kriteri olarak değil.

İki farklı tahmin birimi toplanamaz

Yaygın tavsiye şu: geliştiriciler Fibonacci ile puanlasın, UX ekibi S/M/L ile kaba tahmin yapsın, ikisi de planlamaya girsin. Bu aritmetik olarak çalışmıyor. Sprint kapasitesi bir toplamdır ve 13 puanın üstüne bir “M” eklenemez. İki ayrı birim tutuluyorsa UX eforu planda görünüyormuş gibi yapar, kapasite hesabının dışında kalır.

İki seçenek var. Ya UX işleri de hikayelerle aynı puan birimine geçer, ya da S/M/L için yazılı bir karşılık tablosu tutulur (S=2, M=5, L=8 gibi) ve kapasite o tabloya göre toplanır. İlkini daha sağlıklı buluyorum, çünkü tahmin toplantısında tasarımcının masada olması işin ikinci faydasını veriyor: bir arayüz kararının geliştirmede neye mal olduğu, karar daha verilmeden konuşulur. “Bu alanı canlı arama yapalım” önerisi, aynı odada beş puan mı yirmi puan mı olduğunu duyduğunda çoğu zaman kendiliğinden şekil değiştirir.