#NoEstimates tartışması: story point'lerin ne zaman faydalı, ne zaman zararlı olduğu

İki geliştirico grubu dostça karşı karşıya, bir taraf tahmin kartları tutarken diğer taraf akış şemaları ve döngü süresi grafikleri tutuyor, aralarında bir ayrım var Story point'ler yirmi yıldan fazla süredir çevik tahminlemenin varsayılan birimi oldu. Sonra Woody Zuill 2012'de #NoEstimates tweet'ini attı ve tartışma o zamandan beri hiç durmadı. #NoEstimates kampı tahminlemenin israf olduğunu söylüyor. Tahmin yanlısı kamp ise onsuz planlama yapılamayacağını savunuyor. Her iki tarafın da geçerli noktaları var ve her ikisi de durumu abartıyor. Twitter tartışmalarının ötesine baktığınızda gerçekte neyin geçerli olduğu burada.

#NoEstimates aslında neyi savunuyor

Hareket sıklıkla yanlış temsil ediliyor. Woody Zuill, Vasco Duarte ve diğer savunucular "hiçbir şeyi asla tahmin etmeyin" demiyor. Temel argümanları daha spesifik:

• Çoğu tahminleme çabası, daha basit yöntemlerden elde edeceğinizden daha iyi kararlar üretmiyor
• Story point'ler taahhüt, son tarih ve performans metriği olarak yanlış kullanılıyor
• Ekipler, yazılım geliştirmeye harcanabilecek saatleri tahminleme toplantılarında harcıyor
• Geçmiş üretim verisi (sprint başına tamamladığınız öğe sayısı), story point'leri toplamaktan daha güvenilir şekilde teslim tarihlerini tahmin ediyor

Duarte'nin #NoEstimates kitabı veriye dayalı bir durum ortaya koyuyor: ekibinizin her sprint'te kaç story tamamladığını takip ederseniz ve bu story'ler kabaca aynı boyuttaysa, hiçbir zaman puan değeri atamadan Monte Carlo simülasyonları kullanarak teslim tarihlerini tahmin edebilirsiniz. Argüman planlama karşıtı değil. Story point'lerin, daha ucuza alabileceğiniz bilgiyi almanın pahalı bir yolu olduğu şeklinde.

#NoEstimates'in haklı olduğu noktalar

Eleştirilerin bir kısmı yerinde.

Story point'ler performans metriklerine dönüşüyor

Bu en yaygın başarısızlık modu. Bir yönetici Takım A'nın sprint başına 40 puan, Takım B'nin 25 puan teslim ettiğini görüyor ve Takım A'nın daha üretken olduğu sonucuna varıyor. Bu yüzden Takım B tahminlerini şişirmeye başlıyor. Birkaç sprint içinde story point'ler, ekibin hissettiği baskıdan başka bir şey ölçmüyor. Scrum Rehberi buna karşı açıkça uyarıyor, ama sürekli oluyor. Puanlar bir hedef haline geldiğinde, bir tahminleme aracı olarak işe yaramaz hale geliyor.

Tahminleme toplantıları gerçek zaman yiyor

Yedi geliştiriciden oluşan bir ekibin 20 backlog öğesini tahmin etmek için iki saat harcaması 14 kişi-saat maliyetli. Bu tahminler herhangi bir kararı değiştirmiyorsa, bu 14 saatlik israf. İstikrarlı backlog'ları ve öngörülebilir işleri olan ekipler için tahminleme töreni tam olarak bu hale gelebilir: bir tören.

Yanlış hassasiyet iyi muhakemeyi öldürüyor

Bir şeyin 5 mi yoksa 8 mi olduğunu yirmi dakika tartışmak, gerçek sprint planlama toplantılarında olan gerçek bir şey. Fibonacci dizisi, sayılar arasında sıçramalar zorlayarak bunu önlemek için tasarlandı, ama ekipler hala bunun üzerinde kafa yoruyor. O zaman story'yi daha küçük parçalara bölmeye harcanması daha iyi olur. Geliştirici, tahmin numaraları ve soru işaretleriyle dolu bir beyaz tahtaya bakarken, kafasını karıştırmış şekilde kaşırken, arka planda takım arkadaşları tartışıyor

#NoEstimates'in çöktüğü noktalar

Hareketin kör noktaları da var.

Küçük, tekdüze story'ler varsayıyor

"Sadece story'leri say" yaklaşımı, yalnızca story'ler kabaca aynı boyutta olduğunda işe yarıyor. Duarte bunu kabul ediyor ve öğeler birbirleriyle değiştirilebilir kadar küçük olana kadar her şeyi bölmeyi öneriyor. Bu iyi bir uygulama, ama aynı zamanda bir tahminleme biçimi. Her story'yi böldüğünüzde örtük olarak "bu bir 1 olacak kadar küçük" diyorsunuz. Sadece açık tahminlemeyi örtük tahminleme ile değiştirmiş oluyorsunuz. Çeşitli işler üzerinde çalışan ekipler — bir hafta altyapı, sonra frontend özellikleri, ardından üçüncü taraf entegrasyonları — tüm story'lerin eşit olduğunu varsayamaz.

Yeni ekiplerin kalibrasyona ihtiyacı var

İki yıldır birlikte olan bir ekip genellikle tahminlemeyi atlayabilir çünkü paylaşılan zihinsel modelleri var. Yeni bir API endpoint oluşturmanın veya bir sayfayı yeniden tasarlamanın neyi içerdiğini kabaca biliyorlar. Geçen ay kurulan bir ekip buna sahip değil. Story point'ler ve daha da önemlisi onlar etrafındaki tartışmalar, paylaşılan anlayışı hızlı bir şekilde oluşturuyor. Bir geliştirici 3 tahmin edip diğeri 13 tahmin ettiğinde, takip eden konuşma, ekibin işi gerçekten öğrendiği yerdir. Üretim verisi, kıdemli geliştirici mevcut API'yi kullanacağınızı varsayarken junior geliştiricinin yeni bir tane oluşturacağınızı varsaydığını ekibinize öğretemez.

Paydaşların tahminlere ihtiyacı var

Ürün yöneticileri, satış ekipleri ve yöneticiler story point'lerle ilgilenmiyor. Ama şunu bilmeleri gerekiyor: "X özelliği Nisan'daki konferanstan önce yayınlanacak mı?" Üretim tabanlı tahminleme bu soruyu cevaplayabilir. Story point'leri kullanarak hız tabanlı tahminleme de yapabilir. #NoEstimates kampının burada uygulanabilir bir alternatifi var, ama birçok ekibin özellikle bir projenin başlarında veya önemli ekip değişikliklerinden sonra sahip olmadığı geçmiş veriye ihtiyaç duyuyor.

Story point'lerin değerini kanıtladığı durumlar

Tahminlemenin kendini amorti ettiği durumlar var: İlk aşama ekipler. Planning poker'dan yapılandırılmış konuşmalar paylaşılan anlayışı hızlı oluşturuyor. Tahminlerin kendisi, ortaya çıkardıkları anlaşmazlıklardan daha az önemli. Karışık karmaşıklıkta backlog'lar. Backlog'unuz "bir buton rengini değiştir" ile "ödeme sistemini taşı"yı yan yana içerdiğinde, story'leri boyutlandırmadan saymak çöp tahminler üretiyor. Takımlar arası koordinasyon. Paylaşılan bir yol haritasına katkıda bulunan birden fazla ekip, ürün yöneticilerinin değiş tokuş kararları verebilmesi için ortak bir boyutlandırma diline ihtiyaç duyuyor. Kapsam kaymasını tespit etme. İstikrarlı hız ama kaçırılan taahhütler mi var? Tahmin edilen ve gerçek puanlar arasındaki fark, story'lerin sprint'e girdikten sonra büyüdüğünü söylüyor. Ekip bir masa etrafında toplanmış, planning poker kartları dizili, bazı kartlar eşleşen numaralar gösterirken diğerleri çılgınca farklı değerler gösteriyor, canlı tartışma kıvılcımları çıkıyor

Story point'lerin ne zaman atlanması gerektiği

Story point'ler diğer bağlamlarda yük haline geliyor: İstikrarlı üretimi olan olgun ekipler. Ekibiniz 18+ aydır birlikteyse ve sprint başına tutarlı sayıda benzer boyutlu story bitiriyorsa, üretim verisi size ihtiyacınız olanı zaten söylüyor. Kanban tarzı akış. Sprint'ler yerine sürekli akış kullanan ekipler, önceden tahminlemeden döngü süresini (öğelerin başlangıçtan bitişe kadar geçen süresi) takip etmekten daha fazla şey elde ediyor. Spike'lar ve araştırma görevleri. Keşif çalışmasını tahmin etmek, tahmin hakkında tahmin yapmaktır. Bunun yerine zaman sınırı koyun: "Bunu araştırmak için iki gün harcayacağız ve bulduklarımızı rapor edeceğiz." Bakım ve destek çalışması. Hata düzeltmeleri ve operasyonel görevler reaktiftir. Üretimi takip etmek, her bileti ayrı ayrı tahmin etmekten daha mantıklı.

Çoğu ekibin gerçekte ihtiyaç duyduğu orta yol

Faydalı cevap "her zaman tahmin et" veya "asla tahmin etme" değil. Yaklaşımınızı bağlamınıza uydurmak.

Bağlam	Yaklaşım
Yeni ekip, karmaşık ürün	Story point'lerle planning poker. Konuşma sayılardan daha önemli.
Yerleşmiş ekip, çeşitli iş	Hafif tahminleme (T-shirt boyutları veya hızlı planning poker). Hızlı tutun.
Yerleşmiş ekip, tekdüze iş	Üretimi takip edin. Tahminlemeyi atlayın.
Takımlar arası yol haritası planlaması	Üst düzey tahminleme için story point'ler veya T-shirt boyutları kullanın.
Destek/bakım	Döngü süresi ve üretimi takip edin. Bireysel biletleri tahmin etmeyin.

Çoğu ekip ortada bir yere düşüyor: ihtiyaç duydukları story'leri tahmin ediyorlar ve rutin işler için tahminlemeyi atlıyorlar. Bu iyi. Amaç hiçbir zaman mükemmel bir sisteme sahip olmak değildi. Amaç, ne inşa edeceğiniz ve ne zaman yapılacağı hakkında yeterince iyi kararlar vermek.

Her iki tarafın da haklı olduğu noktalar

#NoEstimates hareketi faydalı bir soruyu zorladı: "Bu tahminleme oturumundan değer mi alıyoruz, yoksa sadece formaliteyi mi yerine getiriyoruz?" Her ekip bunu düzenli olarak sormalı. Tahmin yanlısı kamp, yaklaşan iş hakkında yapılandırılmış tartışmanın sürprizleri önlediği konusunda haklı. Planning poker işe yarıyor çünkü sayılar doğru değil, konuşmalar gizli karmaşıklığı ortaya çıkarıyor sprint ortası problem haline gelmeden önce. Kazanan yaklaşım her ikisinden de ödünç alıyor: faydalı tartışma ürettiğinde veya tahmin doğruluğunu iyileştirdiğinde tahmin edin. Ritüel haline geldiğinde durun. Ekibiniz planning poker kullanıyorsa, Kollabe odağı tartışmada tutan, törende değil, hızlı tahminleme oturumlarını destekliyor. Ve bunun yerine üretimi takip ediyorsanız, o da işe yarıyor. Size daha iyi tahminler ve daha az sprint ortası sürpriz veren şeyi kullanın. 10/02/2026 tarihinde son güncelleme