Küçük ekiplerde (1–5 kişi) Agile’a başlamak, büyük organizasyonlardaki “tam seremonili” şablonları birebir kopyalamaktan farklı bir ihtiyaçtır: Toplantı süreleri hızlıca maliyet olur, bazı sorumluluk alanları aynı kişide birleşebilir ve teslimat baskısı yüksektir. Bu rehberin amacı, Scrum Guide’daki resmi tanımları baz alıp küçük ekip gerçekliğine uygun, uygulanabilir bir ilk sprint planı çıkarmanıza yardımcı olmaktır.

Not: Aşağıdaki örnekler pratik bir başlangıç içindir. Kendi ürününüz, regülasyon gereksinimleriniz, ekip deneyiminiz ve teknik borç düzeyinize göre uyarlamanız gerekir.

1) Scrum mı, Kanban mı? Küçük ekipler için hızlı karar çerçevesi

Agile, tek bir yöntem değildir. Küçük ekiplerde en sık iki seçenek öne çıkar: Scrum (sprintlerle iteratif) ve Kanban (sürekli akış). Scrum, zaman-kutulu (time-box) etkinliklerle ritim sağlar; Kanban ise işi akışta optimize etmeye odaklanır.

Bağlama göre değişmekle birlikte, yeni başlıyorsanız ve ekipte ürün geliştirme odağı varsa 1–2 haftalık Scrum sprinti çoğu küçük ekip için anlaşılır bir başlangıç olabilir. İşiniz ağırlıkla bakım, destek, küçük talepler ve kesintilerden oluşuyorsa Kanban yaklaşımı daha uygun olabilir. Küçük ekiplerde iki yaklaşımın hibrit kullanımı da görülebilir; ancak önce birini temel alıp öğrenme döngüsü oluşturmak genellikle daha kolaydır.

Scrum’un “neden”ine ve Scrum Master odağındaki pratik sorulara göz atmak için: Scrum Alliance: Five Questions Scrum Masters Should Be Able to Answer.

2) Scrum’un resmi temel kuralları: küçük ekip için bilmeniz gerekenler

Scrum’un resmi tanımı ve zaman-kutuları için birincil kaynak Scrum Guide 2020 (PDF) belgesidir. Küçük ekipte esneklik alanını doğru kullanmak için önce çerçeveyi doğru anlamak yararlı olur:

• Sprint uzunluğu: Scrum Guide’a göre Sprint, en fazla bir ay sürer.
• Sprint Planning zaman-kutusu: Scrum Guide, 1 aylık Sprint için Sprint Planning’in en fazla 8 saat olacağını belirtir (daha kısa Sprintlerde genellikle daha kısadır).
• Temel etkinlikler: Sprint Planning, Daily Scrum, Sprint Review ve Sprint Retrospective.
• Temel çıktılar: Product Backlog, Sprint Backlog ve Increment.

Küçük ekip gerçeği: Scrum’da Product Owner, Scrum Master ve Developers hesap verebilirlikleri (accountabilities) ayrı ayrı tanımlıdır. Çok küçük ekiplerde (ör. 1–3 kişi) tek bir kişi birden fazla hesap verebilirliği fiilen üstlenebilir; kritik nokta, bu sorumluluk alanlarını açıkça görünür kılmaktır: “önceliği kim belirliyor?”, “süreci kim iyileştiriyor/engelleri kim görünür kılıyor?”, “teslimatı kim yapıyor?” soruları net kalmalıdır.

Küçük ekip uyarlamalarına dair pratik bir çerçeve için: Small Scale Scrum (PDF).

3) Küçük ekipler için 2 haftalık sprint: minimum uygulanabilir kurulum

3.1 Sprintten önce netleştirmeniz gereken 5 şey

• Ürün hedefi (kısa): “Bu çeyrekte kullanıcı X için Y değerini artıracağız.” gibi.
• İş tanımı: Basit user story veya görev kartı formatı (başlık + değer + kabul kriteri).
• Definition of Done (DoD): “Bitti” demek için minimum kalite koşulları (ör. testler çalışıyor, kod incelemesi yapıldı, staging’de doğrulandı).
• Takım kapasitesi: 2 haftada gerçekçi kaç iş çıkar? Tatil, destek nöbeti, toplantılar dahil.
• Tek bir görünür pano: Trello/Jira/Linear/GitHub Projects vb. (araçtan bağımsız) ve herkesin her gün baktığı tek yer.

3.2 Sprint uzunluğu seçimi: 1 mi 2 hafta mı?

Resmi üst sınır “en fazla bir ay” olsa da küçük ekiplerde 1–2 hafta sıklıkla daha yönetilebilir olur: daha hızlı geri bildirim, daha küçük risk ve daha az “büyük plan” ihtiyacı. Buna rağmen, çok parçalı işlerde (entegrasyon, kapsamlı refaktör) 2 hafta genellikle daha gerçekçi bir başlangıç olabilir.

Pratik başlangıç önerisi (sezgisel): İlk 2–3 sprintte 2 hafta deneyin. Sonra şu iki sinyale bakarak ayarlayın:

• Sprint içinde işler sürekli bölünüp yetişmiyorsa: sprint süresi uzun veya kapsam fazla olabilir.
• Her sprint “çok az şey” çıkıyorsa: sprint çok kısa olabilir veya planlama fazla iddialı olabilir.

4) Sprint Planning: küçük ekip için adım adım agenda (örnek)

Scrum Guide, Sprint Planning’de Sprint Goal oluşturmayı ve Sprint Backlog’u planlamayı vurgular. Küçük ekiplerde amaç, uzun toplantılar yapmak değil; bir sonraki sprintin odağını netleştirip riskleri görünür kılmaktır.

4.1 Örnek zaman-kutuları (2 haftalık sprint, 1–5 kişi)

Aşağıdaki süreler resmi zorunluluk değil, küçük ekipler için başlangıç sezgisidir. İlk 2–3 sprint sonunda kendi verinize (tamamlanan iş sayısı/akış süresi/aksama nedenleri) göre kalibre edin.

• Toplam: 60–120 dakika (ekibin deneyimine göre)
• 0–10 dk: Sprint hedefi taslağı
• 10–40 dk: En önemli backlog maddelerini seçme (değer + risk)
• 40–90 dk: Seçilen işleri parçalara bölme, bağımlılık/risk kontrolü
• Son 10 dk: Kapasite kontrolü, net sahiplik, “ilk gün ne yapıyoruz?”

Scrum Guide’daki 8 saatlik üst sınır, 1 aylık Sprint içindir; daha kısa sprintlerde planlama süresi genellikle daha kısa tutulur. Planlama “aceleyle bitti” hissi yaratıyorsa, çoğu zaman daha fazla toplantı yapmak yerine kapsamı küçültmek veya işi daha iyi dilimlemek daha iyi sonuç verir.

4.2 Sprint Planning çıktıları (mutlaka yazılı olsun)

• Sprint Goal: Tek cümlelik hedef.
• Sprint Backlog: Seçilen işler + her iş için kabul kriterleri + ilk teknik adımlar.
• Kapasite notu: “Bu sprint 6 geliştirici-gün kapasitemiz var” gibi basit bir not.

5) Örnek sprint planı (2 haftalık): küçük ekip için şablon

Aşağıdaki örnek, 3 kişilik bir ekibin (ürün önceliklendirme + süreci kolaylaştırma + geliştirme sorumlulukları paylaşılmış) küçük bir e-öğrenme ürününde “kayıt/oturum” akışını iyileştirdiği varsayımıyla hazırlanmıştır. Kendi alanınıza uyarlamak için iş başlıklarını ve kabul kriterlerini değiştirin.

5.1 Sprint hedefi (örnek)

Sprint Goal: “Yeni kullanıcıların ilk derse başlamasını kolaylaştırmak için kayıt ve oturum açma akışındaki sürtünmeyi azaltmak.”

5.2 Sprint backlog (örnek tablo)

Küçük ekip ipucu (sezgisel): Tahminleri “S/M/L” gibi göreli tutmak, ilk sprintlerde daha hızlı karar aldırır. 2–3 sprint sonra “S ortalama ne kadar sürüyor?” gibi kendi iç kalibrasyonunuzu çıkarabilirsiniz.

5.3 Kapasite hesabı (basit yöntem)

• 2 geliştirici × 10 iş günü = 20 geliştirici-gün
• Toplantılar, destek işleri, kod inceleme, beklenmeyen işler için başlangıç tamponu (sezgisel): %20–40
• Planlanabilir kapasite ≈ 12–16 geliştirici-gün

Bu tampon oranı bir kural değildir: 2–3 sprint sonunda gerçek kesinti oranınızı ölçüp (kaç gün “plan dışı” gitti?) kendi tampon yüzdenizi güncelleyin.

6) Sprint içi çalışma düzeni: minimum seremoniler, maksimum görünürlük

6.1 Daily Scrum (günlük senkron)

Günlük senkronu 10–15 dakikada tutun. Amaç rapor vermek değil, planı güncellemektir. 3 soru formatı işe yarar:

• Dün Sprint Goal için ne yaptım?
• Bugün ne yapacağım?
• Engel var mı?

6.2 Küçük ekip uyarlamaları: toplantıları birleştirmek mümkün mü?

1–3 kişilik ekiplerde bazı etkinlikleri daha kısa tutmak veya ardışık şekilde birleştirmek pratik olabilir. Small Scale Scrum (PDF), küçük ekiplerde seremonileri kompaktlaştırma fikrini tartışır; yine de Sprint Review ve Retrospective’in “ürün geri bildirimi” ve “süreç iyileştirme” hedeflerini kaybetmemeye dikkat edin.

Scrum Guide ile uyum notu: Scrum Guide, 1 aylık Sprint için Sprint Review’u en fazla 4 saat ve Sprint Retrospective’i en fazla 3 saat olarak zaman-kutular; daha kısa sprintlerde bu zaman-kutuları genellikle daha kısa olacak şekilde ölçeklenir.

Örnek kompakt kurgu (2 haftalık sprint, sezgisel):

• Sprint Review: 30–45 dk (1–2 gerçek kullanıcı senaryosu göster)
• Retrospective: 30–45 dk (1 iyileştirme seç, hemen backlog’a ekle)
• İsterseniz aynı oturumda arka arkaya yapın (toplam 60–90 dk).

7) Ölçme ve öğrenme: küçük ekipte neyi takip etmelisiniz?

Agile’ın değeri, “daha çok metrik” toplamak değil; doğru sinyali hızlı görmek ve uyarlamaktır. Küçük ekiplerde aşağıdakiler genellikle yeterlidir:

• Sprint Goal başarı durumu: Hedef tamamlandı mı, kısmen mi, neden?
• Throughput: Sprintte tamamlanan iş adedi (türlerine göre ayırabilirsiniz).
• Cycle time (kabaca): Bir işin “başladı”dan “bitti”ye kaç gün sürdüğü.
• Plan/gerçek sapması: En büyük sapma nedeni (kapsam büyümesi, kesinti, teknik belirsizlik).

Öneri: İlk 2–3 sprintte sadece bu dört maddeyi düzenli konuşun. Sonra ihtiyaca göre detaylandırın.

8) Araçlar ve AI eğilimi: küçük ekipte nasıl temkinli yaklaşmalı?

Agile uygulamalarında verimlilik ve yatırım geri dönüşü baskısı ile otomasyon/AI kullanımına ilgi artıyor. Örneğin Digital.ai 18th State of Agile (2025) basın duyurusu/özeti, bu temalara dikkat çeker. Anket temelli bu tür raporların örneklemi çoğunlukla büyük organizasyonları daha fazla temsil edebileceğinden, küçük ekipte etkiler farklılaşabilir.

Küçük ekipler için düşük riskli denemeler:

• Ticket açıklamalarını özetletme ve kabul kriteri taslağı çıkarma (son kararı ekip verir).
• Retrospective notlarını temalara ayırma (aksiyonları yine ekip seçer).
• Test senaryosu kontrol listesi taslağı üretme (staging doğrulaması şart).

9) En sık takılan 7 nokta ve pratik çözümler

• Sprint Goal yok: Hedef cümlesi olmadan sprint “iş listesi”ne döner. Çözüm: Tek cümle hedef yazın, her işi bu hedefe bağlayın.
• Aşırı taahhüt: Küçük ekipte bir acil iş bütün planı bozar. Çözüm: Kapasiteye ölçtüğünüz kesintilere göre tampon ekleyin.
• İşler çok büyük: 1 iş 5 gün sürüyorsa görünürlük düşer. Çözüm: 1–2 günlük dilimler hedefleyin.
• “Bitti” tanımı belirsiz: Sprint sonunda sürprizler çıkar. Çözüm: Basit DoD yazın ve panoya asın.
• Review yapılmıyor: Geri bildirim döngüsü kopar. Çözüm: 30 dk bile olsa demo yapın.
• Retro aksiyonsuz: Aynı sorunlar tekrarlanır. Çözüm: Her retroda tek aksiyon seçin ve backlog’a koyun.
• Kesinti yönetimi yok: Destek işleri sprinti yutar. Çözüm: “Destek lane” ve günlük maksimum kesinti limiti belirleyin.

10) Hızlı başlangıç kontrol listesi (ilk sprint için)

1. 2 haftalık sprint takvimini belirle (başlangıç/bitiş, review/retro saatleri).
2. Tek bir pano kur: To Do / In Progress / Review / Done.
3. Definition of Done’u 5–8 maddeyle yaz.
4. Backlog’da en az 10 küçük iş maddesi hazırla (kabul kriteriyle).
5. Sprint Planning yap: Sprint Goal + seçilen işler + kapasite tamponu.
6. Her gün 10–15 dk senkron yap ve engelleri yazılı takip et.
7. Sprint sonunda kısa demo (Review) ve kısa iyileştirme (Retro) yap.
8. Retrodan tek aksiyon seç ve bir sonraki sprint backlog’una koy.

Küçük ekibin gücü hızdır. Scrum’un gücü ise bu hızı sürdürülebilir bir ritme bağlamasıdır. İlk sprintiniz “mükemmel” olmak zorunda değil; önemli olan her sprint sonunda biraz daha netleşen bir çalışma sistemi kurmanızdır.