Sprint sonunda ekip 42 story point tamamladı. Bir önceki sprint 35'ti. Yönetici memnun, grafik yukarı gidiyor. Peki bu rakam gerçekte neyi söylüyor? Velocity metriği eleştirisi tam da bu noktada başlıyor: Story point tahminleri ekipten ekipe, hatta aynı ekipte haftalara göre değişiyor. Bir ekibin 8 puanlık görevi, başka bir ekipte 3 puanlık olabilir. Bu ölçeği karşılaştırılabilir bir verimliliğe dönüştürmek istatistiksel olarak anlamsız. Daha derin sorun şu: Velocity artırmanın en kolay yolu, tahminleri şişirmek. Takımlar zamanla bunu öğreniyor. 3 puanlık işi 5 puan yazan ekip, sprint sonunda daha 'verimli' görünüyor. Sistemi oynayanı ödüllendiren bir mekanizma, asıl davranışı ölçmez; gösterilen davranışı ölçer. Bir diğer tehlike ise hız ile kaliteyi birleştirmek. Teknik borç biriktirerek hızlanan bir ekip, velocity grafiğinde parlak görünürken kod tabanını bir yıkım alanına çeviriyor olabilir. Velocity metriği eleştirisi bu ayrımı görünür kılmadığı için yöneticiler yanlış kararlar alabiliyor. Ne yapılabilir? Tek bir metriğe güvenmek yerine çok boyutlu ölçüm setleri kullanmak daha sağlıklı sonuç verir. Örneğin: - Cycle time (bir işin başlangıçtan teslime kadar geçen gerçek süresi) tahmin hatalarından bağımsız, nesnel bir ölçümdür. - Defect rate veya bug yeniden açılma oranı, hızın kaliteye maliyetini gözler önüne serer. - Team health anketleri, sürdürülebilir tempoyu sayısal bir metrikle birleştirmenin basit ama güçlü bir yoludur. - Deployment frequency ve lead time, gerçek çıktıyı story point'ten çok daha doğru yansıtır. Velocity'yi tamamen atmak da doğru değil. Ekip içi sprint planlamasında göreceli karmaşıklık tahmini olarak kullanıldığında anlamlı. Sorun, bu nicel görünümlü ama öznel ölçüyü dışarıya yönelik performans göstergesi olarak sunmak. Velocity metriği eleştirisi sonunda şunu ortaya koyuyor: Kolay ölçülebilen, ölçülmesi gereken demek değildir. Takımları gerçekten anlamak istiyorsanız, tek bir grafikten değil; kalite, tempo ve süreç sağlığından oluşan bütünsel bir tablodan bakmanız gerekiyor.