Çoğu ürün ekibinde backlog, aciliyetin öldüğü yerdir. İçine giren her şey eklendiği anda acildi — bir müşteri şikâyeti, bir satış talebi, bir rakip özelliği, bir iç fikir. Altı ay sonra hepsi hâlâ orada, hepsi hâlâ acil hissettiriyor ve kimse bir sonraki adımda hangisinin yapılacağını tam olarak bilmiyor.
Sorun araç eksikliği değil. RICE, MoSCoW, Kano, ICE, ağırlıklı puanlama gibi onlarca önceliklendirme çerçevesi var. Sorun, çoğu çerçevenin bir tür sahte kesinlik gerektirmesi — bilinmeyenlere sayı atamak; bu da onları titiz hissettirirken aslında sezgiyi bir elektronik tablodan geçirip aklamaktan öteye gitmiyor.
Gerçekten işe yarayan şey daha basit: dürüstçe değerlendirilen iki boyut ve sonuca göre hareket etme disiplini.
Önceliklendirme iki soruya iner. Birincisi: bu, önemsediğimiz sonucu ne kadar iyileştiriyor? (Etki.) İkincisi: bunu teslim etmek bize ne kadara mal olacak? (Efor.) Geri kalan her şey ya bu ikisinin bir inceltilmesi ya da onlardan bir dikkat dağıtıcıdır.
Güven (confidence) bazen üçüncü bir boyut olarak eklenir — "etki konusunda ne kadar eminiz?" — ve akılda tutulmaya değerdir. Ancak pratikte çoğu ekip ne zaman tahmin yürüttüğünü bilir. Önemli olan, tahmini dürüstçe etiketlemektir; onu 1–5 ölçeğinde puanlayıp bir formüle eklemek değil.
Zor olan matrisi anlamak değil, onu doldururken dürüst olmaktır. Her ekibin yapmak istediği ve aslında "Zaman Tuzakları"na ait olan, ama sürekli "Büyük Bahisler" olarak yeniden sınıflandırılan özellikler vardır. Çerçeve yalnızca ekip etki konusunda dürüst olabilirse işe yarar.
Etki, ekiplerin değerlendirmesi en zor bulduğu boyuttur, çünkü çoğu zaman geleceği tahmin etmeyi gerektirir. Cazip olan, onu sayısal olarak puanlayıp kendini bilimsel hissetmektir. Daha iyi bir yaklaşım nitel ama yapılandırılmış olandır.
Değerlendirdiğiniz her özellik için üç soru sorun:
Ekipler eforu sistematik olarak olduğundan düşük tahmin eder. Bu iyi belgelenmiştir — planlama yanılgısı ve iyimserlik yanlılığıyla ilgilidir — ve özellikle birden fazla sisteme dokunan, ekipler arası koordinasyon gerektiren ya da ekibin daha önce geliştirmediği yetenekleri içeren özelliklerde belirgindir.
İki uygulama yardımcı olur. Birincisi, eforu puanlamadan önce, sonra değil, mühendisliğe danışın. Eforu tek başına puanlayan ürün yöneticileri neredeyse her zaman hafife alır. İkincisi, "bilinmeyen bilinmeyenler" kavramını açık bir efor çarpanı olarak kullanın. Kod tabanının yeni bir alanına, üçüncü taraf bir API'ye ya da yakın zamanda test edilmemiş bir kullanıcı akışına dokunan herhangi bir özellik, bariz işin gösterdiğinden 1,5 kat daha yüksek bir efor puanını hak eder.
Bir ürün backlog'undaki aciliyetin çoğu gerçek aciliyet değil — yakınlıktır (recency). Bir müşteri geçen hafta şikâyet etti, bu yüzden talebi baskıcı hissettiriyor. Bir rakip geçen ay bir şey çıkardı, bu yüzden eşleşmek kritik hissettiriyor. Ama yakınlık önemle aynı şey değildir ve yakınlığa tepki vermek, gerçekten önemli işin ihmal edilmesinin en güvenilir yollarından biridir.
Pratik bir test: bunu geçen hafta değil de altı ay önce duymuş olsaydınız yine de acil bulur muydunuz, diye kendinize sorun. Yanıt hayırsa, iş başında olan stratejik öncelik değil, yakınlık yanlılığıdır. Kaydedin, matrise göre sakin bir şekilde değerlendirin ve sırf taze diye öne çekme isteğine direnin.
Matris her zaman net bir yanıt vermez. İki öğe benzer puanlarla aynı çeyreğe düşer ve yine de birini seçmeniz gerekir. Bu durumlarda iki beraberlik bozucu işe yarar: stratejik uyum (hangisi sizi 18 ay sonra olmak istediğiniz yere daha çok yaklaştırıyor?) ve geri alınabilirlik (yanlışsa hangisini geri almak daha zor?). Stratejik olarak daha uyumlu ve daha kolay geri alınabilir olanı tercih edin.