Story point’ler anlamsızdır, kuyrukları ölçün

• Story point’ler tamamen güvenilir değildir, kafa karışıklığına yol açar ve paydaşlara anlamını sürekli hatırlatmak gerekir
  • Düşük puan değerleri daha isabetlidir, ancak yüksek puan değerleri daha yüksek değişkenlik varsayar ve bir aralığı temsil eder; bu yüzden kesin biçimde toplanamaz
  • Story point’ler zamanı ifade etmez, ancak velocity metriğiyle birleştiğinde fiilen zamanı ima eder; bu da en baştan sayıları ve aralıkları toplama eylemini sorunlu hale getirir
• Yazılım tahmini zordur ve sürecin çıktısı, girdiye kıyasla genellikle çok faydalı değildir
• Az kesintiye uğrayan küçük ekipler doğru tahmin yapıyormuş gibi görünür; bu da çoğu durumda yapılan işin iyi gittiği izlenimini verir
• Capacity tamamen kullanıldığında, tüm işlerin değişkenliği keskin biçimde artar ve bu da tüm tahminleri ve zaman çizelgelerini ciddi şekilde etkiler
• Ölçülen kuyruklar, kısa ve uzun vadeli tahmin sorunlarını çözer, kapsam değişikliklerini doğal biçimde ele alır ve belirsizliği azaltırken büyük ekipler için çok daha değerli bir pratik sunar
• Ölçülen kuyruklar, velocity veya cycle time ile ilgili metriklerden 20 kat daha hızlı şekilde sorunları öngören öncü bir gösterge sağlar

Story point nedir?

• Atlassian’a göre story point, bir ürün backlog maddesini veya başka bir işi tamamen hayata geçirmek için gereken toplam çaba tahminini ifade eden birimdir
• Puanlar karmaşıklığı, iş yükünü, riski veya belirsizliği ve işin miktarını ifade eder
• Karmaşıklık ölçümü göreceli bir kavramdır; farklı ekipler aynı işi farklı değerlendirebilir
• Puanların göreceli doğası nedeniyle ekipler arası karşılaştırma anlamsızdır; bu, yönetim seviyesinde sık görülen bir sorundur

İçsel değişkenlik

• Story point’ler Fibonacci dizisine dayanır; değer büyüdükçe daha fazla değişkenlik ifade eder
• Değişkenliği yüksek puan değerlerini toplamak anlamlı değildir ve velocity metriğinde puanları toplamak hatalıdır
• Goodhart yasasına göre, bir ölçüm hedef haline geldiği anda artık iyi bir ölçüm olmaktan çıkar

Bilinen sorunlar

• Story point’lerin sorunları iyi bilinse de, alternatif tahmin teknikleri de benzer sorunlar yaşadığı için hâlâ kullanılmaktadır
• Story point’in yaratıcısı Ron Jeffries bunu reddeder ve kötüye kullanımını eleştirir
• Scrum’da "Commitment", "Forecast" olarak değiştirildi, ancak hâlâ yanlış kullanılmaktadır
• Tahmin edilenden daha fazla iş çıkarıldığında bile bunun karşılığında azarlanılan paradoksal durumlar ortaya çıkar

ROI ile önceliklendirme

• İşletmeler, kaynakları (zaman, para, araçlar, insanlar) optimize etmek için işleri önceliklendirir
• Geliştirme tahminleri yatırım maliyetini hesaplamak için gereklidir, ancak tahminin kendisi zordur ve maliyetlidir
• Software Estimation: Demystifying the Black Art, tahminin zorluklarını ele alan mükemmel bir kitaptır

Sürecin çıktısı

• Story point tahmin süreci çok zaman alır, ancak ortaya çıkan çıktı değerli değildir
• Düzenli grooming oturumları zaman tüketir ve ekipler arasında tutarlılık olmadan farklı biçimlerde uygulanır
• Story point yerine anlamlı bir iş listesi oluşturmak daha değerlidir

Önerilen alternatif

• T-shirt size ile tahmin yapmak daha iyi bir alternatif olabilir, ancak bunun da sorunları vardır
• Zaman üzerinden tahmin yapmak da benzer sorunlar taşır; ekibin fiilen çalıştığı süre ile iş tarafının beklediği süre farklıdır
• Küçük ekiplerde zaman tahmini iyi çalışabilir, ancak ekip büyüdükçe tahmin doğruluğu düşer
• Donald Reinertsen’ın "The Principles of Product Development Flow" kitabında bir alternatif sunulur
  • Kuyruk (Queue) yönetimine odaklanarak iş akışını optimize etmek temel noktadır
  • Capacity planlaması yapılmalı ve değişkenliği karşılayabilecek tampon kapasite sağlanmalıdır

Çözüm

• Ekip, işi birlikte analiz edip küçük task birimlerine bölerek ve belirsizliği ortadan kaldırarak başlamalıdır
• Task listesi bir kuyruk (Queue) haline gelir ve toplam task sayısı iş büyüklüğünü (Job Size) gösterir
• Story point yerine ortalama task tamamlama oranı (Average Task Rate) tahmin için kullanılır
• İşler, ortalama çalışma hızına göre takip edilir ve iş tamamlama oranı hesaplanır
• Yeni bilgi veya geri bildirim geldikçe task’lar güncellenir ve tahmin de doğal olarak ayarlanır
• Geliştiricilerin tahminle ilgili psikolojik baskı hissetmesine gerek kalmaz

Kuyruk (Queue) öncü göstergedir

• Ortalama task tamamlama oranı, Cycle Time, Velocity gibi ölçümler gecikmeli göstergelerken Queue öncü göstergedir
• Queue boyutu artarsa sorunlar önceden fark edilip müdahale edilebilir

Özet

• Story point’ler kafa karıştırır, güvenilir değildir ve başarısız olacak şekilde tasarlanmıştır
• Bunun yerine ekibin sorunu birlikte anlamaya, belirsizliği gidermeye, işi task’lara bölmeye ve Queue yönetimine zaman ayırması anlamlı ve değerlidir

GN+ görüşü

• Yazıda önerilen kuyruk yönetimi yaklaşımı, çevik geliştirmede tahmin zorluklarını aşmak için gerçekçi bir alternatif gibi görünüyor
• Ancak task’ları küçük parçalara ayırma süreci geliştiriciler için ek emek gerektirebilir ve projenin ilk aşamalarında daha fazla zaman alabilir
• Ayrıca task analizi sürecinde geliştiricilerin aktif katılımı ve dürüst görüş bildirmesi ön koşul olmalıdır
• Öte yandan, geliştirme ekibinin iş gereksinimlerini derinlemesine anlaması ve birlikte düşünmesi gibi olumlu etkiler de beklenebilir

[heal9179]

Bu Kanban metodolojisi değil mi..?

[GN⁺]

Hacker News görüşleri

• Kişisel deneyimime göre story point sayılarının kendisi önemli değildi, ancak ekibin işin karmaşıklığını değerlendirme süreci çok faydalıydı

  • Story point’leri iş süresi tahmini için kullanmak güvenilir bir gösterge değildi
  • Ekip ve domain değişiklikleri, geliştirme dışı işlerin değişkenliği gibi çeşitli nedenlerle story point’lerden kaçınmaya çalıştım
  • Story point kullanan ekiplerde bu, iş anlayışını paylaşma aracı olarak kullanılıyordu

• Scrum Guide’da "Commitment"ın "Forecast" ile değiştirilmesi 2011’de olmadı

  • 2010 ve 2011 kılavuzlarına baktığımda, "Commitment" kelimesi 2011 öncesi sürümlerde yoktu
  • "Forecast", 2020 kılavuzunda "Estimate"in yerini aldı

• İş paketlerini atomik birimlere ayırmak ve kuyruk uzunluğunu ölçmek başka bir boyuttaki sorun

  • İş paketlerini ekiple birlikte rafine ederken story point kullanılabilir
  • Tüm işleri 1 story point’e bölemek verimsizdi
  • Kuyruk uzunluğunu değişkenliğin etkisiyle ilişkilendirmek ilginç bir kavram

• Waterfall yaklaşımının ve zaman birimiyle tahmin yapmanın iyi çalıştığı durumlar da var

  • Küçük bir profesyonel hizmetler ekibinde müşteri gereksinimlerini dokümante edip ekiple görüştükten sonra saat aralığıyla tahmin yapıyoruz
  • Müşteri onaylarsa ayrıntılı tasarım, geliştirme, QA ve release sürecinden geçiyoruz
  • 20 yıldır süreç değişmedi ve yüksek üretkenliğe sahip bir ekip olarak değerlendiriliyoruz

• Story point’ler zaman birimi değil, göreli karmaşıklık ve belirsizliği ifade eder

  • Hikayeleri büyük sayılarla ölçebilmek gerekir
  • Bazı ekiplerde 7’nin üzerinde puan verilmez
  • Başka yerlerde ise 21, 30, 50 puan verildiğini gördüm

• Story point’ler kabaca bir zaman birimiydi

  • Story point’leri net bir zaman birimine oturtmak yanıltıcı olabilir
  • Geliştiricinin bir işe ne kadar zaman harcayacağını öngörmek önemlidir
  • Kuyruk analizinin faydalı olabilmesi için her işin tahmini süresini bilmek gerekir

• Scrum’ı ilk kullanırken Rally kullanıyorduk

  • Story point, tahmini süre ve fiili sürenin hepsini takip ediyorduk
  • Jira’ya geçince zaman takibi ortadan kalktı
  • Tahmini süreler daha doğru hale gelince ekibin iş yükünü dengelemek kolaylaştı

• Story point’ler iş karmaşıklığını tartışırken faydalıydı, ancak hızı ölçmek için uygun değildi

  • Yeni bir mühendis olarak çok sayıda story point tamamladım ama yönetim bunu ayarlamaya çalıştı
  • Karmaşık işleri uygun şekilde değerlendirmek zordu

• Yazılım geliştirme projelerini güvenilir biçimde tahmin etmek zordur

  • Ekiple birlikte işi küçük parçalara ayırıp zaman aralıkları tahmin etmek önemlidir
  • Proje ilerledikçe özellik listesini ve yeni tahmin aralıklarını raporlamak önemlidir

• Zaman birimiyle tahmin yapmak daha iyi bir yöntemdir

  • Story point’ler eninde sonunda zaman birimine çevrilir
  • Scrum’ın karmaşık prosedürlerinden kaçınıp işi tamamlamak daha verimlidir