30 saniyelik özet

Story Points, bir işin tamamlanması için gereken göreli çabayı ifade eden takım içi tahmin birimidir. Relative Estimation, yani göreli tahmin, yeni işi başka işlerle karşılaştırarak büyüklüğünü değerlendirmektir. İş miktarı, karmaşıklık ve belirsizlik bu değerlendirmeyi etkileyebilir. Puanlar sabit bir saat tarifesi değildir; yüksek puan da yüksek müşteri değeri anlamına gelmez. Yöntemin yararı, aynı madde hakkında farklı düşünen kişilerin varsayımlarını konuşabilmesidir. Yönetici açısından puanın kendisinden önce kapsamın, bağımlılıkların ve tahminin hangi koşullarda geçerli olduğunun anlaşılması gerekir.

Neden önemli?

Bir ödeme ekranına yeni seçenek eklemek, sunumda küçük bir değişiklik gibi görünebilir. Fakat ekip sağlayıcının hata davranışını, iade işlemlerini ve kullanıcıya gösterilecek durumları henüz bilmiyorsa görünürdeki ekran büyüklüğü yanıltıcıdır. İşin anlaşılması için yalnızca tasarımın kapladığı alana bakılamaz.

Tahmin görüşmesi bu görünmeyen işleri ortaya çıkarabilir. Bir ekip üyesi daha önce kullandıkları bağlantıyı düşünüyor olabilir. Başka biri yeni sağlayıcının doğrulama kurallarını hesaba katabilir. Farklı tahminler, kimin daha iyimser olduğunu tartışmadan önce insanların aynı kapsamı değerlendirip değerlendirmediğini incelemek için fırsattır.

Product Owner, yani ürün sahibi, bu bilgiyi kapsam ve sıralama kararlarında kullanabilir. Değerli görülen bir isteğin beklenenden büyük olduğu anlaşılırsa daha dar bir kullanım senaryosu seçilebilir. Bazı ihtiyaçlar ertelenebilir veya önce teknik belirsizlik araştırılabilir. Tahmin, ürün kararının girdilerinden biridir; kararın tamamı değildir.

Yönetici için önemli olan, belirsizlik karşısında seçenek üretmektir. Hangi kapsamla başlayabiliriz? Hangi dış bağımlılık teslimatı etkileyebilir? Hangi bilgiyi edinirsek öngörümüz değişir? Tek bir puan görmek bu soruları cevaplamaz; puanın gerekçesini ve dayandığı koşulları da görmek gerekir.

Bu nedenle puan artışını doğrudan verimlilik artışı saymak sakıncalıdır. Ekip aynı işleri daha yüksek puanlamaya başladığında rapordaki toplam yükselir; kullanıcıya sağlanan imkân değişmeyebilir. Yönetim raporu, tahmin ölçeğini ürün başarısının kanıtı gibi sunduğunda yanlış bir teşvik oluşturur.

Terim nedir?

Göreli tahmin, iyi anlaşılan veya tamamlanmış referans işler üzerinden yapılabilir. Yeni madde için “Bu iş hangi referansa benziyor, neden daha büyük veya daha küçük?” soruları sorulur. Referansın kapsamı ve tamamlanma koşulları da bilinmelidir.

Mountain Goat Software’ın referans işlere ilişkin rehberi, puanların yalnızca teknik karmaşıklığı değil toplam çabayı değerlendirdiğini vurgular. Bir değişiklik teknik olarak kolay olsa bile çok sayıda yerde uygulanması ve doğrulanması gerekiyorsa büyüklüğü artabilir. Aynı rehber, referansların ortak anlayışı desteklemesini ve puanların sabit zaman taahhüdü gibi kullanılmamasını önerir.

Yöntem kaynağı: Mountain Goat Software, Story Point Baselines: How to Anchor Relative Estimates.

Definition of Done, yani tamamlanmış sayılma tanımı, ürün çalışmasının karşılaması gereken kalite koşullarını açıklar. Tahmin yapılırken yalnızca kod yazma düşünülüp test ve diğer gerekli çalışmalar dışarıda bırakılırsa değerlendirilen kapsam eksik olur.

Velocity, bir ekibin Sprint başına tamamladığı işin puan toplamı olarak kullanılan planlama göstergesidir. Sprint, kısa ve sabit süreli çalışma döngüsüdür. Geçmiş toplamlar, benzer koşullarda sonraki çalışmaya ilişkin öngörüye katkı sağlayabilir. Ancak ekip yapısı, iş türü, destek yükü veya dış bağımlılıklar değiştiğinde geçmiş verinin uygunluğu yeniden değerlendirilmelidir.

Puanları kullanmak, tarih sorularından kaçınma gerekçesi değildir. Yöneticiye beklenen teslimat aralığını, kapsam seçeneklerini ve öngörüyü etkileyen koşulları açıklamak gerekir. Puan toplamını geçmiş ortalamaya bölmek kaba bir başlangıç olabilir; tek başına kesin tarih veya güven düzeyi üretmez.

Gerçek vaka: Atlassian’da planlama pokeri

Atlassian’ın Dan Radigan imzalı tahmin rehberi, planning poker yönteminin şirket içinde yaygın bir uygulama olduğunu belirtiyor. Planlama pokeri, ekip üyelerinin tahminlerini önce ayrı oluşturup ardından birlikte görünür hale getirdiği bir değerlendirme tekniğidir.

Anlatılan uygulamada ekip bir iş maddesini kısaca tartışıyor, kişiler kendi tahminlerini oluşturuyor ve puanlarını gösteriyor. Tahminler uyuşmadığında farklı değerlerin gerekçeleri konuşuluyor. Bu aktarım, Atlassian’ın kendi çalışma biçimine ilişkin doğrulanabilir bir örnek sunuyor.

Kaynak, yöntemin kullanıldığı belirli bir projede hata oranını veya teslimat süresini ne kadar değiştirdiğini açıklamıyor. Bu nedenle planlama pokerinin ölçülmüş bir iyileştirme sağladığı iddia edilemez. Kullanımın doğrulanması ile etkinin kanıtlanması ayrı konulardır.

Vakadan çıkarılabilecek pratik ders, aynı iş hakkındaki farklı görüşleri görünür kılmaktır. Tahminleri göstermek konuşmanın başlangıcıdır. Bir kişinin farklı kapsam, test ihtiyacı veya bağımlılık düşündüğü anlaşılırsa önce bu fark ele alınmalıdır; yalnızca ortak bir rakama ulaşmak yeterli değildir.

Kaynak: Atlassian, Story points and estimation, Dan Radigan.

Varsayımsal örnek: Yeni ödeme sağlayıcısını değerlendirmek

Bir abonelik ürünü yeni ödeme sağlayıcısıyla çalışmak istiyor. Ekip, daha önce tamamladığı standart form değişikliğini üç puanlık referans olarak kullanıyor. Bu referansın giriş doğrulaması, hata mesajları ve gerekli testleri kapsadığı biliniyor.

Yeni iş için bazı ekip üyeleri beş, biri on üç puan öneriyor. Ürün sahibi ortalama alarak tartışmayı kapatmıyor. Farklı tahmin veren kişi, ödeme sonucunun gecikmeli gelebileceğini ve aynı işlemin tekrar gönderilmesinin birden fazla tahsilata yol açmaması gerektiğini söylüyor.

Diğer üyeler yalnızca başarılı ödeme akışını düşünmüş. İade ve başarısız işlem durumlarının kapsamda olup olmadığı da net değil. Ekip önce beklenen davranışı açıklıyor. Ardından ödeme alma ile iade ihtiyacını, kullanıcı açısından anlamlı ve güvenli kapsamlar oluşturup oluşturamayacağını inceleyerek ayırmayı değerlendiriyor.

Sağlayıcının deneme ortamıyla ilgili bilinmeyenler sürüyorsa teknik inceleme yapılabilir. Technical Spike, belirli bir teknik soruyu cevaplamak için sınırlandırılmış araştırma çalışmasıdır. Burada amaç belirsizliğe yüksek puan verip unutmak değildir; cevaplanacak soru ve incelemenin çıktısı belirlenir.

Yeni bilgiyle tahmin yeniden ele alınır. İlk tahminin değişmesi başarısızlık sayılmaz; kapsamın ve varsayımların neden değiştiği kaydedilir. Ürün sahibi teslimat beklentisini bu bilgiyle günceller. Kullanıcıya fayda sağlanıp sağlanmadığı ise puandan ayrı olarak ödeme deneyimi ve kullanım verileriyle değerlendirilir.

Yaygın üç hata

  1. Puanı sabit saate çevirmek

“Bir puan şu kadar saat” kuralı, göreli ölçeği zaman tarifesine dönüştürür. Tarih ihtiyacını ayrıca ele alın. Geçmiş teslimat örüntüsünü, mevcut kapasiteyi ve bağımlılıkları kullanarak koşulları açık bir öngörü oluşturun.

  1. Ekipleri veya kişileri puanla yarıştırmak

Farklı referanslar kullanan ekiplerin toplamları aynı ölçüyü temsil etmeyebilir. Kişiye puan kotası koymak da ortak çalışmayı parçalayabilir. Yönetim değerlendirmesinde ürün sonuçlarını, kaliteyi ve akıştaki engelleri inceleyin; puanları başarı sıralamasına çevirmeyin.

  1. Ayrışan tahminleri ortalamayla kapatmak

Ortak rakam, ortak anlayış oluştuğunu garanti etmez. En farklı tahminlerin arkasındaki kapsam ve varsayımları dinleyin. Çözülemeyen soruları kaydedin; sayı seçmek için belirsizliği gizlemeyin.

Mini uygulama / şablon

Yaklaşan bir iş için aşağıdaki alanları doldurun.

Kullanıcı ihtiyacı ve beklenen değer
—
Kapsam ve kapsam dışı davranışlar
—
Tamamlanma ve kalite koşulları
—
Karşılaştırılacak referans iş
—
Referanstan farklı iş miktarı
—
Karmaşıklık ve belirsizlikler
—
Bağımlılıklar
—
Ayrı oluşturulan tahminler
—
Tahminler arasındaki farkın gerekçesi
—
Gerekli araştırma veya bölme kararı
—
Son tahminin dayandığı varsayımlar
—
Teslimat öngörüsünü yeniden değerlendirme koşulu
—

Çalışma tamamlandığında yalnızca seçilen puanı tartışmayın. Hangi iş unutuldu, hangi bağımlılık bekleme yarattı, hangi varsayım doğru çıktı? Tek bir örnekten ölçeği bütünüyle değiştirmek yerine benzer işleri birlikte inceleyin. Öğrenilenleri referanslara yansıtın; amacı geçmiş tahmini kusursuz göstermek olan geriye dönük puan değişikliklerinden kaçının.

İlgili terimler

Planning Poker, Velocity, Product Backlog, Backlog Refinement, Sprint Planning, Sprint Goal, Definition of Done, Acceptance Criteria, Technical Spike, Capacity Planning, Cycle Time, Throughput, Forecasting, Prioritization