Agile Backlog'da UX İşleri: Hangi Model Ne Zaman Çalışır

UX işlerinin backlog'a nasıl gireceği, ekiplerin genelde ikinci sprintte fark ettiği bir problem. Araştırma ve tasarım kalemleri ya hiç yazılmıyor ya da yazılıp sürekli erteleniyor. Üç yerleşik model var, üçü de aynı ekipte çalışmıyor.

Birleşik backlog

Tasarım, geliştirme, test ve hata kayıtları tek listede durur, her kalem etiketiyle ayrışır. Kurulumu en ucuz model ve küçük ekiplerde başlangıç noktası burası olmalı.

Avantajı önceliklendirmenin tek yerde ve herkesin gözü önünde yapılması. Zayıf noktası ise şu: aynı listede yarışan bir hata kaydıyla bir kullanıcı testi kalemi karşılaştırılabilir şeyler değil. Hata kaydının maliyeti belli, faydası belli; araştırmanın faydası ancak yapıldıktan sonra ortaya çıkıyor. Bu asimetri her sıralamada araştırmayı aşağı iter ve etiket koymak bunu engellemez.

Görev tabanlı birleşik backlog

Her backlog maddesi yetkinliklere göre alt görevlere bölünür. Bir kullanıcı hikâyesinin altında tasarım, uygulama ve test görevleri ayrı ayrı durur.

Çoğu ekip için doğru cevap bu. UX işi kendi başına yarışan bir kalem olmaktan çıkıp, teslim edilecek işin tamamlanma koşulunun parçası haline gelir; hikâye tasarımı yapılmadan başlayamaz, o yüzden ertelenemez de. Bedeli tahminlemenin zorlaşması ve bazı hikâyelerin sprint sınırını aşması.

Araştırma kalemlerini ayrı bir listede tutmak yerine, sonucu tüketen hikâyenin üstüne "engelleyen" bağıyla asmayı tercih ederim. Bağ kurulduğu anda araştırmanın gecikmesi teslim tarihinde görünür hale gelir, ki sorunun ekipte konuşulmasını sağlayan tek şey de bu.

Çoklu backlog

UX ekibi kendi listesini yönetir, geliştirme ekibi ana backlog'u. Kâğıt üzerinde uzmanlaşma sağlar, pratikte tasarımı geliştirmenin bir veya iki sprint önünde koşan ayrı bir hat haline getirir.

Buradaki maliyet genelde konuşulmuyor. Önden çalışan bir tasarım hattı, öncelikler değiştiğinde çalışmasının bir kısmını çöpe atar ve kayıp oranı doğrudan önceliklendirme oynaklığına bağlıdır. Sprint başına kalemlerin üçte biri yeniden sıralanıyorsa, iki sprint önde üretilen tasarımın ancak 0,67 × 0,67, yani yaklaşık %45'i kullanılabilir kalır. Yarısından fazlası boşa gider. Ekibiniz gerçekten bu oranda mı yeniden önceliklendiriyor, bunu ölçmek bir sprint sürer ve modeli seçmeden önce ölçülmeye değer.

Çoklu backlog'un hakkını verdiği tek durum var: birden fazla ürün ekibinin ortak bir tasarım sistemini paylaştığı yapılar. Orada UX işinin bir bölümü zaten tek bir hikâyeye ait değildir, ayrı bir listede durması doğrudur. Tek ekipli bir üründe aynı yapı, adı konmamış bir şelale sürecidir.

Model seçerken bakılacak şey

Ekip büyüklüğü ve UX olgunluğu gibi genel başlıklar karar vermeye yetmiyor. Somut iki soru daha kullanışlı: bir tasarım kararı üretime çıkana kadar kaç sprint bekliyor, ve son üç sprintte planlanan kalemlerin yüzde kaçı yer değiştirdi. İlk sayı büyükse ayrı hat kurmak cazip gelir; ikinci sayı da büyükse tam olarak bu yüzden kurulmamalı.

Ölçüm kalemi backlog'da yoksa ölçüm de yok

UX işlerini backlog'a taşımanın en çok atlanan parçası burası. "Kullanıcı davranışını ölçelim" cümlesi bir karar değil, en az bir geliştirme kalemi: olayların tanımlanması, arayüze yerleştirilmesi, veri şemasının kararlaştırılması. Bu iş sprint'e girmediyse özellik yayına çıkar, kimse ondan veri alamaz ve bir sonraki sprintte tartışma yine fikirler üzerinden yürür.

Pratik kural: bir hikâyenin tamamlanma tanımına, onun başarısını gösterecek olayın da yayına çıkmış olması eklenmeli. Üç satırlık bir olay tanımı çoğu durumda yeterli, ayrı bir analitik aracı kurmadan önce bunun yapılmış olması gerekiyor.

Model kalıcı değil

Backlog yapısı bir kere seçilip bırakılan bir şey değil. Ekipler genelde birleşik listeyle başlar, işler büyüdükçe görev tabanlı kırılıma geçer, tasarım sistemi ortaya çıktığında bir bölümünü ayrı listeye taşır. Bu sırayı atlayıp doğrudan çoklu backlog'a geçen ekiplerde gördüğüm sonuç hep aynı oldu: tasarım hızlanır, teslim yavaşlar.