Engineering Capacity Planning ve Sprint Velocity 2026: Tahmin, Olcum ve Iyilestirme

Yazılım projelerinin gecikme nedenlerinin %48’i kötü kapasite planlaması (Standish Group CHAOS 2026). Tipik bir yazılım ekibinde sprint başına teslim edilen iş %30-50 oranında tahmin edileninden farklı çıkar. Modern bir capacity planning + velocity tracking disiplini, bu sapmayı %10’un altına indirir; proje teslimat hızını %24, stakeholder güvenini %41 artırır. McKinsey Engineering Productivity 2026 raporu, capacity discipline’a sahip ekiplerin engineer başına ürettiği iş öğesini %37 daha fazla bulguluyor. Türkiye’de teknoloji şirketlerinin %62’sinde hâlâ “hangi gün hangi mühendis hangi göreve düştü” sorusuna doğru cevap verecek bir capacity dashboard’u yok.

Bu rehberde modern engineering team capacity planning yöntemlerini, sprint velocity ölçümünü, story estimation pratiklerini, araç stack’ini ve bir engineering manager’ın iki haftalık ritmi nasıl operasyonelleştirmesi gerektiğini somut sayılarla aktarıyoruz.

Velocity Tanımı ve Doğru Yorumu

• Sprint başına tamamlanan story point (veya iş öğesi).
• Stabil ekip için ortalama velocity zamanla sabit (variance ≤ %15).
• Yeni başlayan ekip: ilk 3-5 sprint gürültü dönemi — bu döneme “calibration phase” denir.
• 3-month rolling average öncelikli metrik; tek sprint yanıltıcı.
• Velocity hedef değil, gözlemlenen sonuç. Hedef yapılırsa Goodhart’s Law devreye girer.
• Ekipler arası karşılaştırma toxic — her ekibin baseline’ı kendine özel.

Velocity’i doğru yorumlamak için variance da izlenmeli. Ortalaması 30 SP olan ama 18-45 arasında salınan bir ekip, ortalaması 25 SP olan ama 23-28 arasında salınan bir ekipten daha “az predictable” — yani teslimat planları daha az güvenilir.

Story Point Estimation

Fibonacci Series

• 1, 2, 3, 5, 8, 13, 21.
• Karşılaştırma kolay (“X’ten 2x mi yoksa 3x mi büyük?”).
• Planning poker ile ekip konsensüsü; outlier oylar tartışılır.
• 13+ story point = bölünmeli (epic).
• Atlassian 2025 anketine göre Fibonacci agile ekiplerin %68’i tarafından kullanılıyor.

T-shirt Sizing (Alternatif)

• XS, S, M, L, XL.
• Hızlı kaba tahmin (roadmap için).
• Detaylı sprint için Fibonacci tercih edilir.
• Stakeholder iletişimi için kolay anlaşılır.

Ideal Hour

• “Bu task kaç saat sürer ideal koşulda?”
• Junior developer’lar için daha sezgisel.
• Story point’e göre daha yanıltıcı (gerçek saat eşit değil — interruption, meeting, context switch hesaba katılmıyor).
• Yönetim taraflarına “kaç saat” raporlanması zorluyor — politik baskı yaratıyor.

#NoEstimates Hareketi

• 2015 sonrası popülerleşen “estimation yapma, flow metric’leri izle” yaklaşımı.
• Story sayısı + cycle time’a güvenir.
• Küçük, eşit boyutlu story disiplini gerektirir.
• Stabil, mature ekipler için ilginç alternatif; karmaşık enterprise context’inde zor.

Capacity Hesabı

• 2 haftalık sprint = 10 iş günü.
• Developer başına günlük 5-6 saat actual work (toplantı, code review hariç).
• Engineer-day = 5 saat (tipik orta-büyük şirket).
• 5 kişilik ekip × 10 gün × 5 saat = 250 engineer-hour / sprint.
• İzin, tatil, eğitim, on-call görevleri çıkarılır.
• Net %70 capacity → 175 engineer-hour gerçekçi.
• Yeni iyileştirme: AI code assistant kullanımı (Cursor, Copilot) ortalama developer productivity’sini %18-30 artırıyor (GitHub 2026 study) — bu kazanç quality budget’a yönlendirilmeli, daha fazla iş değil.

Capacity vs Commitment Dengesi

Commitment %	Sonuç	Önerilen Durum
50-60%	Yetersiz kullanım, slack çok	Strategic R&D fazı (geçici)
70-80%	Sağlıklı; %20-30 buffer var	Sürdürülebilir baseline
85-95%	Kıl payı; tek beklenmedik iş ekipte kriz	Sprint sonu burnout sinyali
100%+	Burnout, kalite kaybı, teknik borç birikimi	Acil müdahale gerekli

Engineering manager’ların en sık yaptığı hata: stakeholder baskısıyla commitment’ı %95’in üstüne çıkarmak. Bu kısa vadeli “iyi görünüm” yaratıyor ama 3-4 sprint sonra ekip burnout’a giriyor ve velocity %30-40 düşüyor — net pozisyon negatif. Code quality metrikleri ile birlikte izlendiğinde commitment-velocity-quality üçgeni net görülüyor.

Velocity Stabilizasyonu

• İlk 3 sprint büyük dalgalanma — normal, müdahale etme.
• 5-8 sprint sonrası stabilize. Bu noktadan sonra trend istatistiksel anlamlı.
• Major change (yeni teknoloji, refactor, ekip değişikliği) velocity’yi 1-2 sprint düşürür — beklenen.
• Beklenmeyen yüksek velocity → quality kontrol şart. Test coverage düştü mü, technical debt arttı mı?
• Gradual velocity drop trend’i (3+ sprint) → onboarding gerek, mimari sorun, ya da morale problemi.

Sprint Planning Akışı

1. Backlog refinement: bir hafta önce story estimation. PO + tech lead + 1-2 senior dev.
2. Sprint planning meeting: ekip velocity’sine göre commit. 2 saat max, structured agenda.
3. Sprint goal: 1-3 cümlelik ana hedef. Tek satırlık “value statement” ekip moralini güçlendiriyor.
4. Daily standup: blocker tespit. 15 dk max, “no problem-solving in standup” disiplini.
5. Mid-sprint review: yarı zamanda gözden geçirme (opsiyonel; risk profili yüksek sprint’lerde önerilir).
6. Sprint review/demo: stakeholder ile demo. Çalışan kod gösterimi zorunlu.
7. Retrospective: süreç iyileştirme. “What went well / What didn’t / Action items” klasik format.

Araçlar

• Jira: En yaygın, mature, enterprise feature seti zengin. Atlassian ekosistemine kilitliyor.
• Linear: Modern, hızlı UI, developer-friendly. Velocity tracking ve Cycles feature built-in.
• Shortcut (eski Clubhouse): Linear alternatifi; daha karmaşık org yapıları için.
• GitHub Projects: Git-centric ekipler; basitlik en büyük avantajı.
• Azure DevOps: Microsoft ekosistemi; enterprise + .NET stack için zorunlu.
• Asana, ClickUp: Daha generic, dev-spesifik değil; cross-functional team için iyi.
• LinearB, Jellyfish, Sleuth: DORA + velocity automasyon — manuel toplama yükünü ortadan kaldırıyor.

DORA Metrikleri ile Birleşim

• Deployment Frequency: Günde kaç deploy? Elite: günde 1+. High: haftada 1-7.
• Lead Time for Changes: Commit → production süresi. Elite: <1 saat.
• Change Failure Rate: Deployment’ların % kaçı incident. Elite: 0-5%.
• MTTR: Incident’tan sonra recovery süresi. Elite: <1 saat.
• Yüksek DORA + stabil velocity = sağlıklı ekip. Engineering OKR çerçevesinde her iki metric grubunun da birlikte takip edilmesi standart hale geldi.

Türkiye Özelinde Capacity Dinamikleri

• Türk şirketlerinin %47’sinde mesai sonrası “ufak iş” beklentisi var — gerçek capacity figürünü çarpıtıyor.
• Cumartesi mesai talebi sık (özellikle finans + e-ticaret) — burnout’a katkıda bulunan en büyük faktör.
• Resmi tatil + dini tatil yoğun: yıllık 14.5 gün ortalama, sprint planlarına dahil edilmeli.
• “Mavi yaka kültürü” engineering’e taşınınca: aktivite görünür olmazsa “çalışmıyor” algısı. Bunu kırmak için async update + transparent dashboard zorunlu.
• Yurtdışı remote’a giden senior dev kaybı: capacity bütçesinde sürekli sızıntı. Retention odaklı pricing kritik.

Yaygın Hatalar

• Story point’i saat’e çevirmek → estimation politik.
• Ekipler arası velocity karşılaştırması → toxic, kalibrasyon farkını ıskalıyor.
• Sprint commitment %100+ → burnout.
• Refinement atlama → planning yavaş, estimation gürültülü.
• Retrospective skip → süreç iyileşmiyor.
• Velocity’i performance review’a bağlama → sandbagging başlıyor.
• Tek bir sprint’in velocity’sine reaction → noise’a reaction.
• Holiday + on-call’ı capacity’den çıkarmama → sürekli underdelivery.

Long-Term Capacity Forecasting

Sprint düzeyi tactical capacity planning, ama strategic planning için 6-12-24 aylık forecasting gerekiyor. Modern engineering organizasyonlar şu yapıyı kullanıyor:

• Çeyreklik capacity planning: Hangi takım hangi initiative’e ne kadar zaman ayıracak.
• Yıllık headcount planı: Mevcut velocity + business growth target ile gereken yeni hire sayısı hesabı.
• “Capacity tax” disiplini: Total engineering time’ın %15-20’si “infrastructure / debt / hiring time” — feature delivery’ye değil.
• Critical path analizi: Roadmap’teki en dar boğaz hangi ekip, hangi skill set.
• Buffer for surprises: Yıllık planlamanın %25-30’u “unknown unknowns” için ayrılır.

Engineering Manager Ritmi

• Günlük: Standup (15 dk), blocker takip, ekip moralinin atmosferik göstergesi.
• Haftalık: 1:1 (her dev ile 30-45 dk), tech lead sync, stakeholder update.
• Sprint ritmi (2 hafta): Planning + retro + review + refinement.
• Aylık: 1:1 (skip-level), velocity trend review, hiring pipeline check.
• Çeyreklik: Career conversation, OKR check-in, roadmap alignment.
• Yıllık: Performance review, compensation cycle, team retrospective.

Sık Sorulan Sorular

Ömer Önal’dan pratik not: Türkiye’deki 30-80 kişilik mühendislik organizasyonlarına capacity planning danışmanlığı verdiğimde en sık karşılaştığım problem, “sprint kapanmıyor” sendromu. Sebep çoğunlukla sprint commitment’ının %90 üstünde olması ve “küçük yan iş” trafiğinin hesaba katılmaması. Pratik bir disiplin: her sprint için “planned %70 + buffer %30” formülü; bu %30 buffer’ı strategically iki parçaya bölün (acil yan iş için %15, planlı küçük iyileştirme için %15). Bu yapıyla teslimat sapması %10 altına indi, ekip morali görünür şekilde yükseldi, retrospective’ler “blame oyunu” olmaktan çıkıp “süreç iyileştirme” oturumlarına döndü. Sizin ekibinizde commitment yüzdesi şu an ne — sürekli underdelivery yaşıyor musunuz yoksa buffer kültürü yerleşti mi?

Sonuç

Capacity planning ve velocity tracking, predictable delivery’nin temel taşı. Doğru disiplin (Fibonacci estimation + 3-month rolling velocity + DORA metrics + retrospective + %70 commitment baseline) ile sprint sapması %10 altına iner, teslimat hızı %24 artar, stakeholder güveni güçlenir. SaaS pricing, OKR ve KPI ve code quality metrikleri birlikte ele alındığında engineering ops’unuz baştan aşağı kalibre olur. İletişim formundan projeniz için engineering ops danışmanlığı talep edebilirsiniz.

Dış otorite kaynaklar: Atlassian Agile · DORA State of DevOps · ThoughtWorks Insights · Standish Group CHAOS