Article

Sprint Takibi: Küçük Takımlar İçin Hafif Süreç Alios ile

Scrum ve Jira küçük takımlar için çoğu zaman fazla ağırdır. Alios'ta küçük takım sprint takibini hafif bir backlog–done akışıyla nasıl kuracağınızı öğrenin.

Sprint Takibi: Küçük Takımlar İçin Hafif Süreç Alios ile

Sprint Takibi: Küçük Takımlar İçin Hafif Süreç Alios ile

Scrum teoride mantıklı. Sprint planlama, daily standup, sprint review, retrospektif — hepsi iyi niyet taşıyan pratikler. Ama 4 kişilik ekipte Jira'ya girilip story point tahmin edildiğinde, velocity chart takip edildiğinde, iki saatlik sprint planlama yapıldığında bir noktada şu soru çıkıyor: "Bunu kim için yapıyoruz?"

Küçük takım sprint takibi büyük ekip süreçlerinin küçültülmüş hali değil. Baştan küçük ekip için tasarlanmış, sade ama çalışan bir süreç olmalı.

Scrum Küçük Takımlarda Neden Ağır Geliyor?

Scrum belirli bir ekip büyüklüğü ve olgunluk seviyesi için tasarlandı. Bu eşiğin altında bazı pratikler değer üretmek yerine yük yaratıyor.

Seremon maliyeti yüksek. Sprint planlama, daily, review, retro — bunların toplam süresi küçük ekipte haftanın önemli bir bölümünü alıyor. Ekip iş yapmak yerine iş yapmayı planlamak için toplanıyor.

Story point tahminleri anlamsızlaşıyor. Velocity hesaplamak için en az 4-5 sprint verisi gerekiyor. Yeni ekipte bu veri yok. Tahminler rastgele, velocity grafiği anlamsız.

Roller gereksiz oluyor. Scrum Master, Product Owner, Development Team — 3 kişilik ekipte bu roller aynı kişide toplanıyor. Rol ayrımı değer üretmek yerine terminoloji yükü yaratıyor.

Araç süreci domine ediyor. Jira'da board kurmak, epic-story-task hiyerarşisi oluşturmak, sprint başlatmak — bunlar öğrenmesi ve sürdürmesi zaman alan işlemler. Araç amaca değil, amaca araç oluyor.

Küçük takım için gereken şey Scrum'ın hafifletilmiş hali: sprint döngüsü var, akış görünür, kapanış tanımlı. Ama seremon minimumd, araç sade.

Alios'ta Dört Aşamalı Sprint Akışı

Alios'ta küçük takım sprint takibi dört durumla kuruluyor: Backlog → In Progress → Review → Done.

Bu dört durum yeterli. Daha fazlası küçük ekip için gürültü.

Backlog

Yapılması planlanan ama henüz aktif sprint'e alınmamış her görev. Backlog node'ları öncelik sırasına göre sıralı duruyor.

Backlog node özellikleri:
- Başlık: Aksiyon içeren tek cümle
- Öncelik: Kritik / Yüksek / Orta / Düşük
- Tahmini efor: Küçük (yarım gün) / Orta (1-2 gün) / Büyük (3+ gün)
- Açıklama: Bağlam ve kabul kriterleri
- Sorumlu: Atanmamış veya önceden belirlenmişse atanmış

Backlog'u canlı tutmak için haftada 15 dakika yeterli: geçerliliğini yitiren node'lar kapatılıyor, yeniler ekleniyor, öncelikler güncelleniyor.

In Progress

Sprint'e alınan ve aktif çalışılan node'lar. Bir kişide aynı anda 2-3'ten fazla "In Progress" node olmamalı — daha fazlası odak dağılmasının işareti.

In Progress node'una geçerken eklenenler:
- Sorumlu atandı
- Deadline netleştirildi
- Kabul kriterleri yazıldı (yoksa)
- Bağımlılıklar not edildi

Review

Geliştirme tamamlandı, başkasının bakması gerekiyor. Kod review, ürün onayı, QA testi — hepsi "Review" durumunda yaşıyor.

Review node'una geçerken eklenenler:
- Ne tamamlandı — kısa özet
- Review edilecek kişi atandı
- Staging linki veya test ortamı bilgisi
- Varsa test senaryoları

Review süresi 24 saati geçmemeli. Geçiyorsa blokaj olarak işaretlenmeli.

Done

Kabul kriterleri karşılandı, review tamamlandı, canlıya alındı veya teslim edildi. Node kapatılıyor.

Done kriterlerini karşılamak için:
- Kabul kriterleri tek tek kontrol edildi
- Review eden onayladı
- Canlıya alındı veya teslim edildi
- Varsa müşteri bilgilendirildi

"Neredeyse bitti" Done değil. "Son rötuşlar kaldı" Done değil. Kriterler karşılanmadan node kapatılmıyor.

Örnek: 1 Haftalık Sprint

Alios'ta küçük takım için bir haftalık sprint nasıl görünür:

Pazartesi — Sprint Planlaması (30 dakika)

📁 SPRINT 12 — 24-28 Mart
Hedef: Ödeme akışı iyileştirmeleri canlıya alınacak,
kullanıcı profil güncellemesi review'a girecek.

🔵 IN PROGRESS — Bu hafta yapılacaklar

- Stripe webhook entegrasyonu
  Sorumlu: Ali — Deadline: Çarşamba
  Efor: Orta
  Kabul kriteri: Başarısız ödeme bildirimi
  gerçek zamanlı çalışıyor, test senaryoları geçiyor

- Ödeme geçmişi sayfası
  Sorumlu: Mehmet — Deadline: Perşembe
  Efor: Orta
  Kabul kriteri: Kullanıcı son 30 günün işlemlerini
  görebiliyor, export butonu çalışıyor

- Kullanıcı profil güncelleme — fotoğraf yükleme
  Sorumlu: Zeynep — Deadline: Perşembe
  Efor: Büyük
  Kabul kriteri: JPG/PNG yükleniyor, otomatik
  kırpılıyor, profilde görünüyor

⚪ BACKLOG — Bu haftaya taşınan

- Push notification altyapısı
  Neden taşındı: Firebase erişimi henüz yok
  Sonraki sprint: Sprint 13

- Toplu kullanıcı export
  Neden taşındı: Bu haftaki önceliğin altında
  Sonraki sprint: Sprint 13

Salı-Perşembe — Günlük Güncelleme (5 dakika/kişi)

Toplantı yok. Her kişi sorumlu olduğu node'u güncelliyor:

[Tarih] — Ali: Webhook temel entegrasyonu tamam,
test senaryoları yazılıyor

[Tarih] — Mehmet: Veri modeli hazır, frontend
başlandı. Blokaj: Tasarım onayı bekleniyor

[Tarih] — Zeynep: Yükleme çalışıyor, kırpma
arayüzü entegrasyonu devam ediyor

Mehmet'in blokajı görünür hale geldi. Tasarım onayı bekleniyor — node "Review" durumuna geçiyor, tasarımcıya atanıyor.

Cuma — Sprint Kapanışı (20 dakika)

📋 SPRINT 12 KAPANIŞ — 28 Mart

✅ TAMAMLANANLAR
- Stripe webhook entegrasyonu → Done
  Tüm kabul kriterleri karşılandı, canlıya alındı

- Kullanıcı profil fotoğraf yükleme → Done
  Staging'de onaylandı, Pazartesi canlıya alınacak

⏳ TAMAMLANAMADI
- Ödeme geçmişi sayfası → Sprint 13'e taşındı
  Neden: Tasarım onayı geç geldi, 2 gün kayıp
  Sprint 13'te öncelik: Kritik

📊 SPRINT ÖZETİ
Planlanan: 3 node
Tamamlanan: 2 node
Taşınan: 1 node — sebep kayıt altında

🔄 BİR SONRAKI SPRINT'E NOT
Tasarım onayı bu sprint'te gecikti. Sprint 13
planlamasında tasarım onayları önceden alınacak.

Sprint Kapanış Kriterleri

Bir sprint kapanmış sayılmak için şu kontroller tamamlanmış olmalı:

✅ SPRINT KAPANIŞ KONTROL LİSTESİ

Görevler:
- [ ] "In Progress" node kalmadı
      (kalan varsa Done veya Sprint N+1'e taşındı)
- [ ] "Review" node'ları tamamlandı veya taşındı
- [ ] Tamamlanan her node Done kriterlerini karşıladı

Dokümantasyon:
- [ ] Tamamlanamayan node'ların neden taşındığı yazıldı
- [ ] Sprint özeti node açıklamasına eklendi
- [ ] Bir sonraki sprinte not düşüldü

Backlog:
- [ ] Taşınan node'lar backlog'da önceliklendirildi
- [ ] Yeni gelen talepler backlog'a eklendi
- [ ] Sonraki sprint için ön seçim yapıldı

Retrospektif notu:
- [ ] Bu sprint ne iyi gitti? [1-2 cümle]
- [ ] Ne zorladı? [1-2 cümle]
- [ ] Bir sonraki sprint'te ne değişecek? [1 madde]

Retrospektif toplantı değil, node açıklamasına üç satır. Küçük ekip için bu yeterli — ve sürdürülebilir.

Story Point Yerine Ne Kullanılır?

Küçük takım sprint takibinde story point yerine efor büyüklüğü kullanmak daha sağlıklı:

Küçük: Yarım gün veya daha az
Orta: 1-2 gün
Büyük: 3-5 gün
Epic: 5 günden fazla — parçalanmalı

Bu sınıflandırma velocity hesabı yapmıyor ama sprint kapasitesini planlamak için yeterli. "Bu sprint'e kaç orta, kaç küçük görev sığar?" sorusu sprint planlamasını gerçekçi kılıyor.

Velocity yerine takip edilecek metrik: tamamlanma oranı. Sprint başında kaç node planlandı, kaçı Done'a ulaştı? Bu oran sprint sonunda kayıt altına alınıyor. Zaman içinde tahmin kalitesi kendiliğinden artıyor.

Son Düşünce

Küçük takım sprint takibi Scrum'ın tüm seremonlarını küçük ekibe uygulamaktan geçmiyor. Geçtiği şey şu: düzenli döngü var, akış görünür, kapanış tanımlı, öğrenme kaydediliyor.

Alios'ta dört durum — Backlog, In Progress, Review, Done — ve haftalık rutin bu ihtiyacı karşılıyor. Jira board'u kurmak yok, velocity grafiği yorumlamak yok, story point tartışması yok.

Sprint hafif ama görünür. Ekip küçük ama organize.

Related articles

More articles

Explore other guides connected to this workflow.