Agile’da story point tanıtıldığında “size” demek’ti. Story’nin büyüklüğü. Zamanla ilgili değil. Ama çoğu ekip bunu dönüştürdü: “1 point = 1 saat”, “3 point = yarım gün”, “8 point = 1 hafta”.
Bu mental model yanlış ve zararlı. 10 yıllık agile gözlemlerimden doğru estimation yaklaşımını paylaşacağım.
Story point’in orijinal anlamı
Mike Cohn “Agile Estimating and Planning” kitabında (2005) tanıttı. Kavramsal olarak:
- Size: İşin ne kadar büyük olduğu
- Complexity: İşin ne kadar karmaşık olduğu
- Uncertainty: Bilinmeyenler
Story point bu 3’ünün combined estimate’i. Zaman değil.
Fibonacci scale: 1, 2, 3, 5, 8, 13, 21. Belirsizliği reflect ediyor. Küçük farklar (1 vs 2) net, büyük farklar (13 vs 21) yaklaşık.
Neden zaman değil?
Zamanı tahmin etmek zor:
– Developer’ın deneyimi farklı
– Task’ın blocker’ları önceden bilinmez
– Context switching cost
– Unexpected complexity
Story point size-relative. “Bu task diğer task’lardan 2x büyük” intuitively easier than “3 saat sürecek”.
Team velocity (sprint’te completed point sayısı) zamanla calibrate oluyor. “2 hafta’da 30 point yapıyorsak, gelecek sprint 30 point alabiliriz” planning.
Common antipatterns
Antipattern 1: “1 point = 4 saat” formülü
Yönetim pressure’ı ile developer’lar point’i saate çeviriyor. Point anlamını kaybediyor.
Antipattern 2: Per-story hour estimation
Sprint planning’te her story için “bu 3 saat”, “bu 8 saat” diyenler. Micromanagement tetikliyor.
Antipattern 3: Cross-team point comparison
Team A 50 point/sprint, Team B 30 point/sprint. “A daha hızlı” deduction. Point relative. Her team’in scale’i farklı olabilir.
Antipattern 4: Estimation to impress
Developer low estimate veriyor (“hızlıyım”), sprint sonunda complete etmiyor. Trust kaybı.
Antipattern 5: No estimation at all
“Agile means no estimation”. Extreme stance. Planning için estimation gerekiyor. Sadece obsession yapmamak.
Planning Poker
Team estimation session. Her developer story için point’ini gizli oy veriyor, simultaneously reveal.
Process:
- Product Owner story’yi sunuyor
- Team clarification soruları
- Herkes Fibonacci card’ı seçiyor (kendi tahmini)
- Simultaneously reveal
- En düşük ve en yüksek tahminler konuşuyor (“neden 2? neden 13?”)
- Discussion sonrası re-vote
- Converge olunca kabul
Bu process:
– Team collective intelligence’ı topluyor
– Hidden assumptions ortaya çıkıyor
– Junior + senior perspektifi dengeleniyor
– Consensus built, individual rather ownership
Reference story kalibrasyon
Story point relative. “Reference story” ile calibrate ediliyor.
Example:
– “Add a logout button” = 2 points (simple, understood)
– “Build user profile page” = 5 points (medium)
– “Migrate authentication to OAuth 2.0” = 13 points (complex, uncertain)
Yeni story’ler referance story’lere göre tahmin ediliyor. “Bu profile page’den biraz daha kompleks, 8 point”.
Yeni team’de ilk 2-3 sprint reference story establishment için.
Velocity tracking
Team velocity = sprint’te completed story point’ler.
Monitoring:
– Sprint 1: 28 points
– Sprint 2: 32 points
– Sprint 3: 30 points
– Sprint 4: 35 points
– Sprint 5: 29 points
Average ~31. Gelecek sprint planning 30 point target.
Dikkat: Velocity fluctuation normal. Holiday, illness, dependency blocker etkisi olur. 3-4 sprint running average daha reliable.
Estimation in new teams
Yeni team’de ilk aylar estimation painful:
- Reference story yok
- Team productivity belirsiz
- Complexity estimate miscalibrated
Approach:
- İlk sprint arbitrary points at. Bitmesin zorunlu değil.
- Sprint sonunda retrospective: “Bu story ne kadar zor’du? Point’i doğru muydu?”
- 3-4 sprint sonra reference story’ler establish.
- Velocity stabilize oluyor.
- 6 ay sonra estimation disciplined.
Bu süreç rushed olamaz. Team dynamics zaman alıyor.
T-shirt sizing alternative
Story point yerine T-shirt sizing (XS, S, M, L, XL):
- XS: trivial
- S: small, well-understood
- M: medium, some complexity
- L: large, significant work
- XL: very large, should be broken down
Avantaj: numerical false precision yok. “5 vs 8” tartışması olmuyor.
Dezavantaj: velocity tracking zor. S ve M’nin numerical equivalent’ini kendin tanımlıyorsun.
Bazı team’ler bu yaklaşımı tercih ediyor. Senior’ların estimation’a tolerant’ı artıyor.
NoEstimates movement
Some teams estimation’ı tamamen reddediyor. “Throughput tracking” kullanıyorlar: sadece completed story count.
Reasoning:
– Estimation time-consuming
– Often inaccurate
– Creates false commitment
Prerequisite:
– Stories roughly same size (breakdown discipline)
– Stable team
– Flexible delivery expectations
NoEstimates extreme. Most org’lar bunu accept edemez (budget, roadmap, stakeholder expectation). Hybrid approach mümkün: estimation sadece major epic’ler, day-to-day story sadece throughput.
Estimation vs commitment
Kritik ayrım:
Estimation: “Sanırım bu 5 point civarı.”
Commitment: “Bu sprint’te 30 point teslim edeceğim.”
Estimate uncertainty range (“5 point, ama 3-8 arası olabilir”). Commitment definite.
Yönetim genelde bunları karıştırıyor. Estimate’i commitment gibi tutuyor. Developer defensive estimation yapıyor (buffer koyuyor). Trust erozyonu.
Better framing: “Team bu sprint forecast’i 30 point. Gerçekleşen 25-35 arası olabilir. Risk faktörleri: X, Y.”
Tools that help
- Jira: Velocity report, sprint planning, story points built-in
- Linear: Modern alternative, estimation simpler
- Shortcut (Clubhouse): Estimate-focused project management
- Asana: Basic estimation, good for smaller teams
Tool opinionated. Team’inin workflow’una uyan’ı seç.
Estimation hygiene
Do:
– Story point’i size için kullan, zaman için değil
– Reference story’lerle calibrate
– Team consensus ile estimate (planning poker)
– Retrospective’de estimate vs actual reflect
– Velocity trend izle, outlier investigate et
Don’t:
– Point’i saat’e çevirmeye çalışma
– Cross-team velocity compare etme
– Estimate’i rigid commitment olarak sun
– Junior developer’ı pressure’la düşük estimate’e
– Sprint sonrası “estimation yanlıştı” blame game
Sonuç
Story point zaman değil, size. Bu mental model doğru kurulduğunda estimation disciplined, team dynamics healthy, planning realistic.
Planning poker, reference story, velocity tracking core tool’lar. T-shirt sizing veya NoEstimates alternatives for different contexts.
Estimation hiç mükemmel olmuyor. “Good enough” yeter. Over-engineering estimation process’i kendi başına waste.