Neden Adam*Saat Yerine Story Point?
Story Point tahminlemesi, Scrum ekipleri tarafından sıklıkla kullanılan bir yöntem. Sprint başlangıçlarında ekibin Sprint içerisinde ne kadar iş alacağına bu yolla karar veriliyor. Bu yaklaşımda her bir kullanıcı hikayesine bir Story Point değeri atanıyor. Bu değer işin büyüklük ve karmaşıklığını gösteren sayısal bir değer oluyor. Sprint Planlama sonucundaysa ekibin geçmiş performanslarına da bakılarak, Sprint içinde ne kadarlık bir büyüklük ve karmaşıklığı ele alabileceğine karar veriliyor.
Peki geleneksel adam*saat tahmini yerine neden böyle bir yaklaşım tavsiye ediliyor? Adam*saat tahmini yapılırken ekiplerde genel bir kesin-precise tahminleme eğilimi oluyor. Bu iş 2,5 saatte, 7 saatte yapılır gibi. Bu genelde ekip içerisindeki daha tecrübeli kişilerin tasarrufuna kalıyor. Veya konsensüs sağlanmaya çalışıldığında da zaman alıcı olabiliyor. Çevik yaklaşımdaki görüş ise tahminlemenin bir tahminleme olarak kalması, kesin değerlere ulaşmak için harcanan çabanın bir israf olduğu. Tahminleme için gerekli bir zamanın ayrılması konusunda herkes mutabık ancak tahminlemeye harcanan efor ile yakalanan doğruluk arasında doğru bir orantı olmadığını söyleyebiliriz (Resim 1). Tahminlemede, Sprint planlamaya girdi olabilecek kabaca doğru tahminleri yakalamak yeterli, kesin tahminler için çaba harcamak israf olduğu gibi yanıltıcı da olabiliyor.
Story Pointler atanırken ekiplerin kesinlik yanılgısından uzaklaşması ve tahminlemeleri daha hızlı gerçekleştirebilmesi için fibonacci sayıları tavsiye ediliyor. Buradaki mantık iş büyüdükçe aradaki küçük farkların anlamını yitirmesi, bu nedenle aralıkların genişlemesi. Örneğin 12 ve 13 SP arasındaki farkı anlamlandırmak zor olacaktır. Fibonacci önerilen bir pratik sadece, aşağıda epic seviyesindeki büyük storylerde benim de yaptığım gibi (20, 40 vs.) buradaki aralıkları ekip olarak siz belirleyebilirsiniz, . Adı story point de olmak zorunda değil, dilerseniz <Proje İsmi> Point gibi bir jargon kullanın. Çünkü bu tamamen ekibin öznel görüşü üzerine yapılan bir tahmin, hatta her ekip ayrı bir jargon bile kullanabilir. Keza atanan aynı değerdeki story point, iki farklı ekipte farklı büyüklük ve karmaşıklığı ifade ediyor olabilir. Bu nedenle story pointin ekip dışına çıkıldığına anlamını yitirdiğini unutmamak gerek.
- 1–2–3–5–8–13–20–40…
Story Point atamaları gerçekleştirilirken ekip içinde konsensüs sağlamak tercih ediliyor. Bunun için yaygın kullanılan yöntem Planning Poker. Her bir ekip üyesi kendi görüşünü, bir diğer ekip üyesinin etkisi altında kalmadan paylaşıyor. Bunun sonucunda aykırı değerler ekip içinde tartışılarak konsensüs sağlanmaya çalışılıyor. Bu tartışma önemli, çünkü bir ekip üyesinin işle ilgili gördüğü bir risk diğer ekip üyelerinin tahminlerini güncellemelerine sebep olabiliyor. Burada yapılan tahminler birbirine yakınsayana kadar iteratif olarak tahminlemenin yapılması tavsiye ediliyor. Ekibin birlikte çalışarak, ne tür işlerde ne gibi puanlar verdiğini birlikte kararlaştırması, ileriki Sprintlerde işini kolaylaştırıyor.
Son olarak yöneten bakış açısıyla sık yapılan bazı yanlışları da vurgulamak lazım. Birincisi, story point bir üretkenlik göstergesi değildir. Sadece ekiplerin kabaca doğru planlar yapabilmeleri için belirledikleri öznel değerlerdir. İkincisi, ekibe özgü olduklarından farklı ekipleri kıyaslamak için kullanılmamaları gerekir. Ekip içinde bir performans değerlendirmesi yapılması da doğru değildir, çünkü yine ekip üyeleri tarafından yapılan kabaca doğru tahminlerdir. Story Point’in bir üretkenlik veya performans göstergesi olarak değerlendirilmesi ekipler tarafından şişirilmesi tehlikesini oluşturur ve bu da sağladığı faydayı kaybetmemize sebep olacaktır. Story Point iş değeriyle de ilişkili değildir, küçük puanlı bir özellik daha büyük puanlı bir özellikten daha fazla iş değeri taşıyabilir. Özetle, Story Pointi Sprint ve Release planlarında, iş büyüklüklerini kabaca tahminleyerek, sadece karar almamıza yardımcı bir enstrüman olarak düşünmemiz gerekiyor. Bundan öte yükleyeceğimiz anlamların faydadan çok zararı olacaktır.
[1]: Essential Scrum: A Practical Guide to the Most Popular Agile Process, Kenneth Rubin, Addison Wesley, 2012
