Story Points ile Çevik Tahminleme: Planning Poker'dan Kapasite Planlamaya

Çevik tahminleme neden saatle değil, göreli büyüklükle yapılır?

Yazılım ve ürün geliştirme işlerinde belirsizlik yüksektir. Bir işin kaç saat süreceğini önceden söylemek, işi yapacak kişiye, o günkü kesintilere ve işin henüz bilinmeyen yönlerine bağlıdır. Çevik ekipler bu yüzden mutlak süre yerine göreli büyüklük tahmin eder: Bu iş, daha önce yaptığımız şu işten daha büyük mü, küçük mü?

Story point, bir kullanıcı hikayesinin ya da backlog öğesinin göreli büyüklüğünü ifade eden birimdir. Büyüklük; işin hacmini, karmaşıklığını ve belirsizliğini birlikte yansıtır. Story point saat ya da gün karşılığı değildir; ekibin kendi içinde tutarlı olması yeterlidir. Scrum çerçevesi belirli bir tahmin yöntemi zorunlu kılmaz, story points yaygın ama isteğe bağlı bir tekniktir.

Referans iş belirlemek ve Fibonacci ölçeği

Göreli tahmin için önce bir referans iş seçilir. Ekibin iyi bildiği, küçük ya da orta büyüklükte bir iş referans kabul edilir ve diğer işler bununla kıyaslanır. Örneğin basit bir form alanı eklemek referans olabilir; bir ödeme entegrasyonu ise referanstan açıkça daha büyük, belirsizliği daha yüksek bir iş olarak puanlanır.

Çoğu ekip puanlamada Fibonacci benzeri bir ölçek kullanır: değerler büyüdükçe aralarındaki fark artar. Bunun nedeni, büyük işlerde tahminin doğruluğunun düşmesidir. Büyük iş için hassas bir puan vermeye çalışmak yanıltıcıdır; ölçekteki boşluklar bu belirsizliği dürüstçe yansıtır. Çok büyük çıkan iş, tahmin edilmeden önce daha küçük parçalara bölünür.

Planning Poker nasıl uygulanır?

Planning Poker, ekibin tahmini birlikte ve birbirinden etkilenmeden yapmasını sağlayan bir tekniktir. Akış şöyledir: • Ürün sahibi ya da ilgili kişi backlog öğesini kısaca anlatır • Ekip, kapsam ve kabul ölçütleri hakkında soru sorar • Herkes aynı anda gizlice bir puan seçer ve aynı anda gösterir • Puanlar farklıysa en yüksek ve en düşük puanı verenler gerekçesini anlatır • Tartışmanın ardından ekip yeniden oy verir ve uzlaşmaya varılana dek devam eder

Tekniğin değeri puandan çok tartışmadadır. Biri "çok kolay" derken diğeri "çok riskli" diyorsa, ortada bilinmeyen bir bağımlılık ya da farklı bir kapsam varsayımı vardır. Bu fark, işe başlamadan önce ortaya çıkar.

Velocity ve kapasite planlama

Velocity (hız), ekibin bir sprintte tamamladığı işlerin story point toplamıdır. Birkaç sprint boyunca izlenen velocity, bir sonraki sprintte ne kadar iş alınabileceğine dair gerçekçi bir fikir verir. Planlama, ekibin dileğine göre değil, geçmiş performansa göre yapılır.

Örneğin ekibin son sprintlerde benzer miktarda iş tamamladığını biliyorsanız, sprint planlamasında bu miktara yakın bir yük almak makuldür. Velocity ekip içi bir planlama aracıdır; ekipleri birbiriyle kıyaslamak ya da performans skoru gibi kullanmak anlamsızdır, çünkü her ekibin puan ölçeği kendine özgüdür. Takvim ve izin gibi kapasite değişikliklerini de planlamaya katmak gerekir.

Alternatif tahminleme yöntemleri

Story points her ekip için en uygun yöntem olmayabilir. Giysi bedenleri (küçük, orta, büyük gibi) göreli büyüklüğü rakamsız ifade eder ve ilk kez tahmin yapan ekipler için sezgisel bir başlangıçtır. Bazı ekipler ise her işi benzer boyuta bölerek tahmini tamamen bırakır ve yalnızca tamamlanan iş sayısını izler.

Bu yaklaşımlar arasında seçim yaparken ekibin olgunluğu, işin türü ve paydaşların ihtiyacı belirleyicidir. Kanban benzeri akış odaklı ekiplerde iş sayısı ve çevrim süresi gibi göstergeler çoğu zaman puandan daha kullanışlıdır. Önemli olan, tahminin karar vermeye hizmet etmesi, ritüele dönüşmemesidir.

Sık yapılan hatalar

Story points uygulamasında tekrarlanan hatalar: • Story point'i saat ya da gün olarak çevirmek ve bunu taahhüt saymak • Velocity'yi yönetici için performans ölçütüne dönüştürmek, böylece puan enflasyonuna yol açmak • Tahmini tek kişinin yapması, ekibin tartışmaması • Büyük işi bölmeden tek puanla tahmin etmek • Geçmiş verisine bakmadan sprint yükünü iyimser belirlemek

Puan enflasyonu özellikle yaygındır: Velocity ölçüt olarak baskı altına girdiğinde ekip aynı işe daha yüksek puan vermeye başlar ve ölçü anlamını yitirir. Bu nedenle puanlar ekibin kendi planlaması için tutulmalıdır.

Tahminleme kültürü ve süreklilik

Tahmin bir kez yapılıp unutulan bir iş değildir. Sprint sonunda gerçekleşen sonuç ile tahmin karşılaştırılır, sapmanın nedeni retrospektifte konuşulur. Bir iş beklenenden büyük çıktıysa, hangi bilgi eksikti? Bir sonraki tahminde bu bilgiyi nasıl yakalarız?

Sağlıklı bir tahmin kültüründe yanlış tahmin suçlanmaz, öğrenme fırsatı olarak ele alınır. Paydaşlara tahminin kesin bir söz değil, belirsizlik içeren bir öngörü olduğu açıkça anlatılır. Bu şeffaflık, ekibe baskı altında bile dürüst puan vermesi için alan açar.

Mindset programlarında çevik tahminleme

Mindset'in Çevik Tahminleme ve Story Points programının modülleri bu konuları sırayla işler: çevik tahminlemenin temelleri, Fibonacci dizisi ve story points, Planning Poker uygulaması, hız (velocity) ve kapasite planlama, alternatif tahminleme yöntemleri ile tahminleme kültürü ve gelişim.