Article
AI ile Sprint Planlama: Backlog'u Patlatmadan 1 Hafta
AI iş üretimini hızlandırırken backlog kontrolsüz şişer. Alios'ta AI ile sprint planlamayı backlog akışı, WIP limiti ve kapanış kriterleriyle nasıl kuracağınızı öğrenin.
AI ile Sprint Planlama: Backlog'u Patlatmadan 1 Hafta
AI araçlarıyla çalışmaya başlandığında backlog ilk haftalarda ikiye, üçe katlanıyor. Cursor bir feature'ı saatlerde yazıyor, Claude mimari seçenekler sunuyor, Copilot boilerplate'i saniyede tamamlıyor. Yazmak hızlandı — bu iyi. Ama yazmak hızlanınca "yapabiliriz" listesi de şişiyor.
Sprint planlamasında bu şişme şöyle görünüyor: ekip backlog'a bakıyor, her şey "artık hızlı yazılabilir" görünüyor, sprint'e fazla iş alınıyor. Haftanın ortasında review birikmiş, test yapılmamış, bazı görevler yarım. Cuma günü sprint kapanmıyor.
AI yazma hızını artırıyor ama review, test, entegrasyon ve deployment hızını artırmıyor. Sprint planlaması bu gerçeği yansıtmazsa backlog değil sprint patlıyor.

AI Backlog'u Neden Şişiriyor?
Backlog şişmesinin üç kaynağı var ve üçü de AI kullanımıyla doğrudan ilişkili.
"Artık kolay" yanılgısı. Bir görev AI ile yazılabiliyorsa otomatik olarak küçük görünüyor. Ama yazma maliyeti düşen görevin review, test ve entegrasyon maliyeti düşmüyor. Sprint planlamasında yalnızca yazma süresi hesaba katılınca kapasite aşılıyor.
Fikir üretimi hızlanıyor. AI ile çalışırken "şunu da yapabiliriz" fikirleri daha hızlı geliyor. Her fikir backlog'a girince liste kontrol edilemez büyüklüğe ulaşıyor. Önceliklendirme yapılmadan büyüyen backlog sprint planlamasını anlamsızlaştırıyor.
Yarım görev birikimi. AI birden fazla şeyi paralel başlatmayı kolaylaştırıyor. Geliştirici üç farklı feature için AI'dan kod alıyor, üçünü de "In Progress"e alıyor. Ama üç şeyin review'u, testi ve entegrasyonu ayrı iş. Sprint sonu üç yarım görev, sıfır tamamlanan feature.
Backlog Sağlığını Korumak: Sprint Öncesi 15 Dakika
Sprint planlamasından önce backlog gözden geçirilmiyor, sprint patlıyor. AI çağında bu gözden geçirme daha kritik — çünkü listeye giriş hızlandı.
Sprint planlamasından bir gün önce, 15 dakika:
📋 BACKLOG GÖZDEN GEÇİRME
Her node için şu sorular sorulur:
1. Hâlâ geçerli mi?
[ ] Evet — devam
[ ] Hayır / Değişti → kapat veya güncelle
2. Yazma dışı maliyet tahmin edildi mi?
[ ] Review süresi eklendi
[ ] Test süresi eklendi
[ ] Entegrasyon riski not edildi
3. Kabul kriteri yazılı mı?
[ ] Evet — sprint'e alınabilir
[ ] Hayır → önce yaz, sonra al
4. Öncelik doğru mu?
[ ] Sprint hedefiyle uyumlu → devam
[ ] Uyumsuz → önceliği düşür veya çıkarBu 15 dakika sprint planlamasını gerçekçi kılıyor. Backlog küçülmüyor ama hangi node'ların sprint'e girmeye hazır olduğu netleşiyor.
Sprint Hedefi: Tek Cümle, Ölçülebilir
Sprint planlamasının ilk adımı iş listesi değil, hedef. Hedef yoksa sprint sonu "başarılı mıydı?" sorusu yanıtlanamıyor.
AI destekli geliştirmede sprint hedefi daha da önemli — çünkü AI "yapılabilecekler" listesini genişletiyor. Hedef yoksa her "yapılabilecek" listeye giriyor.
İyi sprint hedefi şu özellikleri taşıyor:
✅ İyi sprint hedefi:
"Ödeme akışı canlıya alınacak — başarılı ödeme
ve başarısız ödeme senaryoları çalışıyor."
✅ İyi sprint hedefi:
"Kullanıcı davet sistemi review'a hazır olacak —
tüm kabul kriterleri karşılandı, staging'de test edildi."
❌ Kötü sprint hedefi:
"Ödeme, davet sistemi ve profil sayfasını yapacağız."
(Üç ayrı hedef = hedef yok)
❌ Kötü sprint hedefi:
"Mümkün olduğu kadar çok şeyi bitireceğiz."
(Ölçülemez = kapanış kriteri yok)WIP Limiti: En Önemli Kural
WIP (Work In Progress) limiti bir kişinin aynı anda "In Progress" durumunda tutabileceği maksimum node sayısı. AI çağında bu kural kritik çünkü AI paralel başlamayı kolaylaştırıyor.
📌 WIP LİMİTİ KURALI
Kişi başı maksimum "In Progress" node: 2
3. bir node "In Progress"e girmeden önce:
→ Mevcut 2 node'dan biri REVIEW veya DONE'a geçmeli
Neden 2?
- 1 aktif geliştirme
- 1 review veya unblock bekleniyor
Neden 3 değil?
- 3 paralel görev = 3 yarım iş
- Context switch maliyeti yazma kazancını siliyor
- Sprint sonu 3 "neredeyse bitti" = 0 tamamlananWIP limiti kısıtlayıcı görünüyor. Ama "daha az başla, daha fazla bitir" prensibini hayata geçiriyor. AI'ın hızını tek bir görevin tamamlanmasına odaklamak, üç yarım görev başlatmaktan her zaman daha verimli.
Alios'ta 1 Haftalık Sprint: Tam Örnek
📁 SPRINT 14 — 24-28 Mart
Sprint hedefi: Ödeme modülü iyileştirmeleri canlıya
alınacak. Başarılı ödeme, başarısız ödeme ve
webhook senaryoları staging'de onaylandı.
Ekip: Ali (backend), Mehmet (frontend), Zeynep (QA)
WIP limiti: Kişi başı 2
📅 PAZARTESİ — Sprint Planlaması (30 dakika)
Sprint'e alınan node'lar:
🔵 IN PROGRESS
- Stripe webhook entegrasyonu
Sorumlu: Ali
AI kullanımı: Claude — entegrasyon şablonu
Yazma tahmini: 4 saat
Review + test tahmini: 3 saat
Toplam: ~1 gün
Deadline: Salı öğlen
Kabul kriteri:
- Başarılı ödeme webhook'u işleniyor
- Başarısız ödeme webhook'u loglaniyor
- Test senaryoları geçiyor
- Ödeme geçmişi sayfası — frontend
Sorumlu: Mehmet
AI kullanımı: Cursor — component üretimi
Yazma tahmini: 3 saat
Review + test tahmini: 4 saat
Toplam: ~1 gün
Deadline: Salı EOD
Kabul kriteri:
- Son 30 günün işlemleri listeleniyor
- Tarih filtresi çalışıyor
- Mobil görünüm düzgün
- Ödeme modülü test checklist
Sorumlu: Zeynep
Başlangıç: Salı (webhook ve frontend hazır olunca)
Deadline: Perşembe öğlen
Kabul kriteri:
- Tüm fonksiyonel testler tamamlandı
- Edge case'ler (başarısız kart, ağ hatası) test edildi
- 0 Kritik, 0 Yüksek öncelikli açık bug
⬜ BACKLOG (bu sprint — sıra bekliyor)
- Hata mesajları iyileştirmesi
Sorumlu: Mehmet — başlangıç: Çarşamba
Koşul: Ödeme geçmişi sayfası DONE'a geçince
- Webhook retry mekanizması
Sorumlu: Ali — başlangıç: Çarşamba
Koşul: Temel webhook DONE'a geçince
❌ SPRINT'E ALINMADI (backlog'da kaldı)
- Toplu ödeme export özelliği
Neden: Sprint hedefiyle doğrudan ilgisi yok,
kapasite doldu
Sonraki sprint: Sprint 15
- Ödeme dashboard widget'ı
Neden: Frontend kapasitesi yok
Sonraki sprint: Sprint 15
📅 SALI
09:00 — Ali check-in:
Webhook temel entegrasyonu tamamlandı.
PR #61 açıldı. Staging'e deploy edildi.
Durum: IN_PROGRESS → REVIEW
Reviewer: Zeynep — deadline: Salı 17:00
10:00 — Mehmet check-in:
Ödeme geçmişi component hazır, API entegrasyonu
devam ediyor. WIP: 1/2, kapasite var.
17:00 — Zeynep review notu:
Webhook PR incelendi. 1 küçük düzeltme istendi
(hata logu formatı). Ali düzeltiyor.
18:00 — Ali:
Düzeltme yapıldı. PR güncellendi.
Durum: REVIEW → DONE bekleniyor.
📅 ÇARŞAMBA
09:00 — Zeynep:
Webhook PR onaylandı. Merge edildi.
Durum: DONE ✅
Ali yeni göreve geçebilir: Webhook retry mekanizması
Durum: BACKLOG → IN PROGRESS
10:00 — Mehmet:
Ödeme geçmişi sayfası tamamlandı. PR #62 açıldı.
Durum: IN PROGRESS → REVIEW
Reviewer: Ali
14:00 — Zeynep test checklist başladı:
Ödeme geçmişi staging'de test ediliyor.
Durum: NOT_STARTED → IN PROGRESS
17:00 — Ali Mehmet'in PR'ını inceledi:
Onaylandı, merge edildi.
Durum: DONE ✅
Mehmet yeni göreve geçebilir: Hata mesajları iyileştirmesi
Durum: BACKLOG → IN PROGRESS
📅 PERŞEMBE
09:00 — Zeynep test notu:
Ödeme geçmişi testleri tamamlandı.
2 bug bulundu:
- BUG-041: Tarih filtresi sıfırlanmıyor — Orta öncelik
- BUG-042: Mobil'de tablo taşıyor — Düşük öncelik
Mehmet bug'lara bakıyor (hata mesajları düşük önceliğe indi)
14:00 — Mehmet:
BUG-041 düzeltildi. PR #63.
BUG-042 düzeltildi. PR #64.
16:00 — Zeynep:
Her iki bug doğrulandı. Kapatıldı.
Test checklist: IN PROGRESS → REVIEW
17:00 — Ali webhook retry mekanizmasını tamamladı.
PR #65 açıldı.
Test: Zeynep sabah bakacak.
📅 CUMA — Sprint Kapanışı
09:00 — Zeynep:
Test checklist tamamlandı: DONE ✅
Webhook retry test edildi: DONE ✅
Hata mesajları iyileştirmesi test edildi: DONE ✅
10:00 — Production deploy:
Tüm PR'lar merge edildi, canlıya alındı.
11:00 — Sprint kapanış (20 dakika):
📋 SPRINT 14 KAPANIŞ
✅ TAMAMLANANLAR
- Stripe webhook entegrasyonu → DONE (canlıda)
- Ödeme geçmişi sayfası → DONE (canlıda)
- Webhook retry mekanizması → DONE (canlıda)
- Hata mesajları iyileştirmesi → DONE (canlıda)
- Test checklist tamamlandı, 2 bug bulundu kapatıldı
📊 SPRINT METRİKLERİ
Planlanan: 5 node
Tamamlanan: 5 node
Devir eden: 0
Bulunan bug: 2 → Kapatılan: 2
AI bağlantılı bug: 1 (BUG-041 — AI filtre logic'i eksik üretmişti)
🎯 SPRINT HEDEFİ
"Ödeme modülü iyileştirmeleri canlıya alınacak."
→ KARŞILANDI ✅
🔄 RETROSPEKTİF NOTU
İyi giden: WIP limiti uygulandı, kimse 2'den
fazla görev almadı, akış tıkanmadı.
Zorlayan: Zeynep perşembe günü 2 PR review
+ test checklist aynı anda geldi — QA yükü
yoğunlaştı. Sonraki sprint'te review deadline'ları
daha erken ayarlanacak.
Bir dahaki sprint'te değişecek: Ali ve Mehmet
PR'larını en geç Perşembe öğlene kadar REVIEW'a
taşıyacak, Zeynep için Cuma sabahı tampon kalacak.Sprint Kapanış Kriterleri
Sprint kapanmış sayılmak için:
✅ SPRINT KAPANIŞ KONTROLLERİ
Görevler:
- [ ] "In Progress" node kalmadı
(kalan varsa sebep yazıldı, Sprint N+1'e taşındı)
- [ ] "Review" node'ları tamamlandı veya taşındı
- [ ] Tüm DONE node'lar kabul kriterlerini karşıladı
- [ ] Açık Kritik veya Yüksek bug kalmadı
AI kalite kontrolü:
- [ ] Her AI üretilen modül için test checklist açıldı
- [ ] Test checklist'lerin tamamı DONE
- [ ] AI bağlantılı bug sayısı ve kategorisi not edildi
- [ ] Bir sonraki sprint AI promptlarına ne ekleneceği
sprint retrospektif notuna işlendi
Sprint hedefi:
- [ ] Sprint başında yazılan hedef karşılandı mı?
[ ] Tam karşılandı
[ ] Kısmen karşılandı — neden: [Açıklama]
[ ] Karşılanamadı — neden: [Açıklama]
Backlog:
- [ ] Devir eden node'ların önceliği güncellendi
- [ ] Yeni gelen talepler backlog'a eklendi
(sprint sırasında gelen ama alınmayanlar)
- [ ] Sonraki sprint için ön seçim yapıldı
Retrospektif notu (3 satır):
- [ ] Ne iyi gitti: [1-2 cümle]
- [ ] Ne zorladı: [1-2 cümle]
- [ ] Bir dahaki sprint'te ne değişecek: [1 madde]Son Düşünce
AI sprint kapasitesini artırmıyor. Yazma hızını artırıyor. Bu fark sprint planlamasının merkezinde duruyor.
Alios'ta sprint hedefi, WIP limiti ve backlog gözden geçirme rutini bu farkı yönetilebilir kılıyor. Backlog şişiyor ama sprint'e giren iş kontrollü. AI hızıyla başlanan görevler WIP limitiyle sınırlanıyor. Sprint sonu sürpriz olmuyor.
"Bu hafta ne yapabiliriz?" sorusunun cevabı artık "AI yazıyor, her şeyi" değil — "AI yazıyor, ama biz planlıyoruz."