Story Point'ler Gerçekten İşe Yarıyor mu? 2026'daki Büyük Tartışma

Bir sprint planlamasında üç saatlik bir toplantıya girdim. İşin yarısı tek bir kartın kaç puan olduğunu tartışmakla geçti. Sonunda Scrum Master 'Tamam, 8 diyelim' dedi ve devam ettiler. Kartı 8 yapan neydi? Kimse tam olarak bilmiyordu. Ama bu numarayla birlikte herkes masadan kalktı ve işi yapmaya başladı.

Bu sahneyi tanıyor musunuz? Story point tartışmaları, Scrum uygulayan neredeyse her ekibin gündeminde. 2025-2026 itibarıyla bu tartışma daha da büyüdü: Deneyimli Scrum Master'lar, takım liderleri ve şirketler 'Story point'leri neden kullanıyoruz?' sorusunu sormaya başladı.

Bu yazıda her iki tarafı da dürüstçe ele alıyoruz. Story point'lerin ne zaman işe yaradığını, nerede bozulduğunu ve ekibiniz için doğru kararı nasıl vereceğinizi konuşacağız.

Story point, bir işin büyüklüğünü soyut bir sayıyla ifade eden tahmin birimidir. Saati temsil etmez. Dakikayı temsil etmez. 'Bu iş ne kadar karmaşık, ne kadar belirsiz, ne kadar emek gerektirir?' sorularının birleşik bir özeti olarak düşünebilirsiniz.

Kent Beck ve Mike Cohn gibi isimler bu yaklaşımı Extreme Programming ve Scrum'a taşıdı. Fibonacci dizisi (1, 2, 3, 5, 8, 13, 21...) veya benzer bir skala kullanılır. Büyük sayılar hem daha büyük iş hem de daha fazla belirsizlik anlamına gelir.

Temel mantık şu: İnsanlar 'Bu kaç saat sürer?' sorusunu yanıtlamakta kötüdür. Ama 'Bu iş şu işten büyük mü, küçük mü?' sorusunu görece iyi yanıtlar. Story point'ler bu göreli karşılaştırmanın aracıdır.

Velocity, bir ekibin geçmiş sprint'lerde ortalama kaç story point tamamladığını gösterir. Son dört sprint'te sırasıyla 34, 38, 36, 40 point tamamladıysanız, velocity'niz yaklaşık 37'dir.

Bu sayı gelecek planlaması için kullanılır: Backlog'daki toplam point miktarını velocity'ye bölersiniz. '150 point, velocity 37, yaklaşık 4 sprint sürer' gibi bir forecast ortaya çıkar.

Kağıt üzerinde güçlü bir araç gibi görünüyor. Ve gerçekten de bazı durumlarda güçlüdür. Ama tam burada, 'bazı durumlarda' ifadesinde sorun başlıyor.

Story point'leri savunanların haklı olduğu noktalar var. Bunları görmezden gelemeyiz.

'Bu iş kaç saat sürer?' sorusu geliştiriciler için rahatsız edici bir baskı oluşturur. Saat verildiğinde bu sayı doğrudan kişisel performansla özdeşleşir. Story point daha soyut olduğu için bu baskı azalır. 'Siz mi yavaş çalışıyorsunuz?' yerine 'Bu iş beklenenden büyük mü?' sorusu öne çıkar.

Planning Poker toplantısında herkes aynı anda kartını açar. Biri 2 verirken diğeri 13 veriyorsa, ikisi aynı işi düşünmüyor demektir. Bu farkı ortaya çıkarmak, sayının kendisinden çok daha değerlidir. Story point'ler bu anlamda konuşmayı açan bir araçtır.

2012-2013 civarında Woody Zuill, Neil Killick ve Ron Jeffries 'Neden tahmin yapıyoruz ki?' diye sormaya başladı. Bu soru başlangıçta küçük bir çevreyi etkiledi. 2020'lerden itibaren çok daha geniş bir kitleye ulaştı. #NoEstimates bir hareket haline geldi.

Temel argüman şu: Tahmin bir yönetim aracıdır, yazılım geliştirme aracı değil. Ekipten 'Ne zaman biter?' sorusu sorulduğunda, bu soru zaten bir baskı içerir. Bu baskı altında verilen tahminler gerçeği değil, yönetimi memnun etmeye çalışan sayıları üretir.

Allen Holub gibi isimler daha da ileri gidiyor: 'Sprint bile gereksiz. Story point kesinlikle gereksiz.' Bu görüş tartışmalı. Ama temel eleştiri — story point'lerin gerçek öngörülebilirlik yerine öngörülebilirlik görüntüsünü optimize ettiği fikri — tamamen görmezden gelinemez.

Büyük kurumsal frameworkler velocity gaming'i yaygınlaştırdı: Ekipler gerçek iş yerine tahminlerini optimize etmeye başladı. Bu çarpıklık tartışmanın yakıtını artırdı.

Story point karşıtlarının güçlü noktaları var. İşte en önemlileri:

Story point'ler kötü değil. Nasıl kullanıldığı kötü. Peki en sık hangi noktada bozuluyor?

1. Velocity bir performans metriği haline gelir: 'Geçen sprint 40 point yaptınız, bu sprint neden 37?' Bunu duyan ekip ne yapar? Tahminlerini şişirir. Bir sprint sonra velocity 50 olur, ama yapılan iş miktarı değişmemiştir.

2. Product Owner sprint'e daha fazla iş sıkıştırmak için kullanır: 'Sprint kapasitemiz 40 point, hadi bir 5 puanlık daha ekleyelim.' İşin değeri mi tartışılıyor? Hayır. Sadece sayı optimizasyonu.

3. Planning Poker konuşma üretmeden geçilir: Herkes 3 diyor, kimse soru sormadan devam ediliyor. Asıl değer — ortak anlayış — ortaya çıkmıyor.

4. Story point saate çevrilir: 'Bir point yaklaşık 4 saat' gibi hesaplamalar başlar. Bu noktada zaten saat kullanıyorsunuz demektir.

5. Farklı ekipler karşılaştırılır: Ekip A'nın 1 point'i ile Ekip B'nin 1 point'i tamamen farklı şeylerdir. Bu karşılaştırma hem anlamsız hem de zararlıdır.

Evet, çalışıyor. Üstelik bazı ekiplerde çok daha iyi sonuçlar veriyor.

2020 Scrum Guide revizyonundan bu yana story point ve velocity kelimeleri Scrum Guide'da yer almıyor. Bu bir tesadüf değil. Scrum.org bu kavramları Scrum'ın zorunlu parçaları olarak değil, opsiyonel pratikler olarak görüyor.

Ekibinizde şu belirtilerden birkaçı varsa bırakmayı düşünün:

Story point'leri sürdürmeniz mantıklı eğer:

Teorik tartışmaların ötesinde, pratikte bir karar vermeniz gerekiyor. Şu adımları öneriyorum:

Önce soruyu doğru sorun: 'Story point kullanmalı mıyız?' yerine 'Neden story point kullanıyoruz?' sorusunu sorun. Bu sorunun yanıtı 'hep böyle yaptık' veya 'Scrum böyle diyor' ise — Scrum Guide story point önermediği halde — durup düşünmek gerekiyor.

Sonra belirtilere bakın: Yukarıdaki 'bırakma' listesindeki maddelerden birkaçı ekibinizde varsa, en azından deneyin. Bir sprint story point olmadan deneyin. Planlama nasıl geçti? Ekip nasıl hissetti? Verimlilik nasıl etkilendi?

Alışkanlığı alışkanlık olduğu için sürdürmek ile bilinçli bir seçim yapmak arasında büyük fark var. Her iki yol da doğru olabilir. Ama farkı bilmeden yürütmek, problemi görünmez kılar.

Story point'ler kötü bir araç değil. Ama 2026'da bunları körü körüne kullanmak için bir neden yok.

Eğer Planning Poker konuşmalarınız gerçek değer üretiyorsa, velocity baskısız bir tahmin aracıysa ve ekibiniz bundan memnunsa — devam edin. Hiçbir şeyi değiştirmenize gerek yok.

Ama eğer 'kaç puan?' sorusu işi tartışmaktan daha önemliyse, tahminler şişiyorsa ya da velocity performans metriği olarak kullanılıyorsa — bu bir araç problemi değil, kültür ve süreç problemidir.

Kültür problemleri araç değiştirerek çözülmez. Ama bazen araç değiştirmek o zor konuşmayı başlatmanın en iyi yoludur.

Story point ile saat arasındaki fark nedir? Saat kesin bir ölçümdür, story point ise görecelidir. Saat '60 dakika' demektir. Story point 'bu işe yaklaşık şu büyüklükte' demektir. İkisi farklı soruları yanıtlar ve birbiriyle doğrudan dönüştürülmemelidir.

Planning Poker nedir? Her ekip üyesinin tahminini aynı anda açıkladığı bir tekniktir. Ankraj hatasını önler. Farklı tahminler en değerli konuşmaları tetikler. 1, 2, 3, 5, 8, 13, 21 veya ? kartlarıyla oynanır.

Velocity neden sprint'ten sprinte değişiyor? Hastalık, tatil, teknik borç, bağımlılıklar ve tahmin hataları velocity'yi etkiler. Bu normaldir. Sorun, velocity'nin değişmesini baskıyla önlemeye çalışmaktır — bu yalnızca şişirilmiş tahminler üretir.

Product Owner tahmine katılabilir mi? Çoğu Scrum Coach katılmamasını önerir. PO'nun iş önceliklendirme perspektifi, teknik tahminleri farkında olmadan etkileyebilir. İşi yapacak olanların teknik boyut konusunda daha iyi bilgisi vardır.

Story point olmadan velocity nasıl ölçülür? Story sayısı, tamamlanan iş miktarı (throughput) veya cycle time iyi alternatifler sunar. Önemli olan tutarlılık: Aynı ölçümü tutarlı şekilde yaparsanız trend görünür hale gelir.