Agile'da UX Kapasitesi: Ayrı Tahmin, Ayrı Takvim
Agile ekiplerde UX işinin yükü genelde geliştirme puanının içine gömülür ve orada kaybolur. Kaybolduğu için de tasarım tarafının doluluğu ancak biri yetişemediğinde fark edilir. Kapasiteyi ayrı ölçmek iki şey verir: gelen işi reddetmek için zemin, ve neyin gerçekte ne kadar sürdüğüne dair birikmiş veri.
UX işi neden geliştirme puanıyla ölçülmez
Story point, bir işin geliştirme tarafındaki emeğini ve belirsizliğini tarif eder. UX tarafındaki emekle bu sayı düzenli olarak örtüşmez. Arayüze bir geri al butonu koymak tasarım tarafında yarım günlük iştir; arka planda ise yapılan işlemin tersine çevrilebilir hale getirilmesi, kimi zaman veri modelinin baştan düşünülmesi demektir. Ters örnek de sık görülür: tek bir formun akışını yeniden kurmak geliştirmede birkaç satırdır, UX tarafında iki haftalık araştırma ister.
İki tahminin ayrılmasının sebebi bu. Aynı iş kartına iki sayı yazarsınız, sprintte ikisini ayrı ayrı toplarsınız.
Ayrı tahmini kurmanın adımları
- Her karta UX tahminini geliştirme tahmininden bağımsız yazın. Aynı 1-2-3-5-8 ölçeği iş görür; ölçeğin ne olduğu değil, ekipte sabit kalması belirleyici.
- Ekibin bir sprintte kaç UX puanı çıkardığını ilk üç sprint boyunca ölçün, tahmin etmeyin. İlk sayı yanlış çıkacak, sorun değil.
- Araştırma, tasarım ve geliştirmeye destek işlerini ayrı toplayın. Destek işi görünmezdir ve kapasitenin şaşırtıcı bir kısmını yer.
- Bir iş UX kapasitesinin yarısından fazlasını yiyorsa bunu planlama toplantısında sayıyla söyleyin, iş kaydığında değil.
Kapasiteyi ayrı bir araca taşımayın. Ekibin zaten her gün baktığı panoya bir alan ekleyin, tahmini oraya yazın. Kimsenin günlük işinde açmadığı bir kapasite aracının ürettiği rapor, ikinci ayın sonunda gerçekle ilgisini keser.
Efor ile takvim aynı şey değil
Hesabın en sık kırıldığı yer burası. Puan efor ölçer, takvim ölçmez. Beş kişilik bir kullanılabilirlik testinin eforu birkaç gündür; katılımcı bulmak, randevulaştırmak ve iptal edenin yerine yenisini koymak ise ekipten kimsenin çalışmasına bağlı değildir ve rahatlıkla iki haftayı geçer. Sprinte sığan efor, sprinte sığan iş demek değil.
Dual-track çalışan ekiplerde bu daha da belirgin, çünkü tasarım tarafı bir sprint önden gider. Aynı sprintin UX ve geliştirme kapasitesini yan yana koyup karşılaştırmak o zaman yanlış hesap olur: iki sayı aynı işe ait değildir. Karşılaştıracaksanız kartın kendisini takip edin, sprinti değil.
Sayı ne işe yarıyor
Kapasite verisinin karşılığını verdiği an, yeni talebin geldiği andır. Bunu yapamayız cümlesi tartışma açar; bu sprintte 21 puanlık UX kapasitemiz var, gelen iş 13 puan, o hâlde şu ikisi çıkacak cümlesi karar aldırır. Aradaki fark, veriyi ihtiyaç duymadan önce toplamış olmak. Talebin geldiği gün ölçmeye başlayamazsınız.
Aynı sayı bir kişinin kaç ekibe bölündüğünü de görünür kılar. Üç ekibe dağıtılmış bir tasarımcıyı her ekip kendi planında yarım zamanlı sayarsa toplam beklenti yüzde 150 olur; kimse bunu bilerek yapmaz, sadece kimse toplama bakmamıştır. Tükenmişlik tartışmasının sayıya bağlanabildiği tek yer de burası.
Tahminleri birkaç sprint sonra geriye dönüp karşılaştırın. Aranan şey isabet değil, sistematik sapma. Araştırma işlerini sürekli düşük tahmin ediyorsanız hata tahmini yapanda değil, araştırmanın takvime bağımlı olmasındadır; onu da puanı büyüterek değil, işi sprintten önce başlatarak çözersiniz.