Yapay Zekâ Çağında Scrum: Sprintler Haftalardan Günlere mi İniyor?

Son iki yılda ekiplerin günlük işine yapay zekâ asistanları girdi. Kod yazmak, test senaryosu çıkarmak, dokümantasyon hazırlamak, bir hatanın kaynağını bulmak artık eskisinden çok daha kısa sürüyor. Bu hız, akla doğal bir soru getiriyor: İş bu kadar hızlı üretilebiliyorsa iki haftalık sprintler hâlâ anlamlı mı? Sprintler haftalardan günlere mi inmeli?

Kısa cevap: Sprint süresi kısalabilir, hatta bazı ekipler için kısalmalı. Ama bunu yapmadan önce yapay zekânın neyi hızlandırdığını ve neyi hızlandırmadığını doğru görmek gerekiyor. Aksi hâlde daha kısa sprintlerle aynı darboğaza daha sık çarparsınız.

Yapay zekâ neyi hızlandırıyor, neyi hızlandırmıyor?

Google’ın DORA araştırma programı bu soruya iki yıldır veriyle bakıyor. 2024 DORA raporu, yapay zekâ kullanımındaki %25’lik bir artışın dokümantasyon kalitesinde yaklaşık %7,5, kod kalitesinde %3,4 ve kod inceleme hızında %3,1 iyileşmeyle ilişkili olduğunu buldu. Aynı rapor, yapay zekâ kullanımı arttıkça teslimat hızında tahmini %1,5, teslimat istikrarında ise %7,2 düşüş gözlemledi.

2025 DORA raporu tabloyu biraz değiştirdi: Katılımcıların %90’ı işte yapay zekâ kullanıyor ve bu yıl yapay zekâ ile teslimat hızı arasında olumlu bir ilişki görülüyor. Ancak istikrarla ilişki hâlâ olumsuz. Raporun ana mesajı tek cümleye sığıyor: Yapay zekâ bir ekibi düzeltmez; ekipte zaten var olanı büyütür. Güçlü test otomasyonu, küçük partiler ve hızlı geri bildirimi olan ekipler kazanıyor. Sıkı bağlı sistemleri ve yavaş onay süreçleri olan ekipler ise daha çok değişikliği aynı dar boğazdan geçirmeye çalışıyor.

Sahadan gözlemimiz de bu yönde. Bir işin “başladı”dan “bitti”ye kadar geçen süresinin büyük kısmı genellikle kod yazarken değil, beklerken geçer: önceliklendirme kararını, iş birimi onayını, kod incelemesini, test ortamını, başka bir ekibin bağımlılığını beklerken. Yapay zekâ yazma kısmını kısaltıyor; bekleme kısmına dokunmuyor. Hatta daha çok iş üretildiği için inceleme ve test kuyrukları uzayabiliyor.

Scrum Rehberi sprint süresi hakkında ne diyor?

Scrum Rehberi sprintleri “bir ay veya daha kısa, sabit uzunlukta” etkinlikler olarak tanımlar. Yani Scrum açısından bir haftalık, hatta daha kısa sprintler meşrudur. Sprint süresini belirleyen asıl soru şudur: Ne sıklıkla öğrenmemiz ve yön değiştirebilmemiz gerekiyor?

Sprint, işin üretildiği bir kutu olmaktan çok bir geri bildirim döngüsüdür. Sprint hedefi, sprint incelemesi ve retrospektif; ekibin “doğru şeyi mi yapıyoruz, doğru mu yapıyoruz?” sorusunu düzenli olarak sormasını sağlar. Yapay zekâ işi hızlandırdıkça bu döngünün daha sık çalışması mantıklıdır. Ama döngüyü kısaltmak, döngünün içindeki her adımı da hızlandırmayı gerektirir. Temel kavramlar için Sprint nedir? ve Scrum nedir? yazılarımıza göz atabilirsiniz.

Sprinti kısaltmadan önce sorulması gereken beş soru

1. Bir iş öğesi bugün ortalama kaç gün bekliyor? Akış verinize bakın: Bir öğenin toplam süresinin ne kadarı aktif çalışma, ne kadarı bekleme? Bekleme oranı yüksekse sprint süresini değil, beklemeyi küçültün.
2. İnceleme kapasitesi üretim hızına yetişiyor mu? Yapay zekâ destekli bir geliştirici günde eskisinden çok daha fazla değişiklik açabilir. Kod incelemesi, test ve onay aynı kişilerin elinde kaldıysa kuyruk büyür.
3. Ürün sahibi ve paydaşlar daha sık karar verebilir mi? Haftalık ya da daha kısa sprintler, haftalık öncelik kararı demektir. Karar vericiler iki haftada bir ulaşılabiliyorsa sprint kısalsa da iş beklemeye devam eder. Product Owner rolü burada kritik.
4. “Bitti tanımı” yapay zekâ çıktısını kapsıyor mu? Üretilen kodun güvenlik, lisans, test kapsamı ve okunabilirlik açısından kimin, nasıl kontrol ettiği tanımlı olmalı. DORA 2025’e göre katılımcıların yaklaşık %30’u yapay zekâ tarafından üretilen koda az ya da hiç güvenmiyor; güven, açık kurallarla kazanılır.
5. Ritüellerin süresi orantılı mı? İki haftalık sprint için tasarlanmış dört saatlik planlama, bir haftalık sprintte yükten başka bir şey değildir. Etkinlikleri sprint süresiyle orantılı küçültün.

Kısalan sprintte ne değişir, ne aynı kalır?

Aynı kalanlar: Sprint hedefi, şeffaflık, inceleme ve retrospektif. Bunlar yapay zekâ çağında daha da önemli; çünkü ekip daha fazla çıktı üretirken “bu çıktı bir sonuca dönüşüyor mu?” sorusunu kaçırmak kolaylaşıyor.

Değişenler:

• İş öğeleri küçülür. Bir öğe bir iki günde bitebilecek büyüklükte olmalı. Yapay zekâ, büyük bir işi küçük ve test edilebilir parçalara bölmekte de yardımcı olabilir.
• Ürün birikimi iyileştirme sürekli hâle gelir. Haftada bir uzun oturum yerine, kısa ve sık netleştirme sohbetleri.
• Günlük toplantı akışa odaklanır. “Dün ne yaptım?” yerine “Panodaki hangi iş en uzun süredir bekliyor ve onu nasıl ilerletiriz?”
• Sprint incelemesi gerçek kullanıcı geri bildirimine yaklaşır. Daha sık canlıya alım, daha sık ölçüm.

Sprint yerine akış: Ne zaman Kanban’a bakmalı?

Bazı ekipler için doğru cevap sprinti bir haftaya indirmek değil, sabit sürelerden tamamen çıkıp sürekli akışa geçmektir. İşler farklı boyutlarda ve öngörülemeyen zamanlarda geliyorsa, ekip birden fazla tedarikçiye bağımlıysa ya da iş birimiyle her gün öncelik konuşuluyorsa Kanban daha doğal bir uyum sağlayabilir. Kanban’da sprint yerine WIP limitleri, hizmet seviyesi beklentileri ve düzenli geri bildirim döngüleri vardır. Geçiş için Kanban’a geçiş rehberimiz iyi bir başlangıç.

Pratikte birçok ekip ikisini birleştiriyor: Sprint hedefi ve incelemesi için Scrum ritmini koruyup, sprint içinde akışı Kanban metrikleriyle yönetiyor.

Yapay zekâ çağında Scrum Master ve ekip

Yapay zekâ, Scrum Master’ın işini azaltmıyor; odağını değiştiriyor. Toplantı notu tutmak, rapor hazırlamak gibi işler otomatikleşirken asıl değer şu sorulara kayıyor:

• İş nerede bekliyor ve bu beklemeyi kim çözebilir?
• Ekip yapay zekâyı nasıl kullanıyor, hangi kurallar herkesçe biliniyor?
• Hız artarken kalite ve istikrar korunuyor mu?
• Daha çok çıktı, daha çok müşteri değerine dönüşüyor mu?

Bu son soru, yapay zekâ çağının en önemli sorusu. Çünkü artık darboğaz “yapabilir miyiz?” değil, “neyi yapmalıyız ve yaptığımız işe yaradı mı?” sorusunda.

Önerimiz: Kısaltmadan önce ölçün

Sprintlerinizi haftalardan günlere indirmeyi düşünüyorsanız şu sırayı öneriyoruz:

1. Son iki üç ayın akış verisini çıkarın: döngü süresi, bekleme süreleri, iş öğesi yaşı.
2. En uzun bekleme noktasını bulun ve önce onu küçültün.
3. Yapay zekâ kullanımı için ekip içi kuralları ve “bitti tanımı”nı güncelleyin.
4. Sprint süresini bir adım kısaltın (örneğin iki haftadan bir haftaya) ve üç dört sprint sonra veriye yeniden bakın.

Ekiplerinizin işinin nerede beklediğini birlikte görmek isterseniz ücretsiz 360 değerlendirmemizle başlayabiliriz. Çevik dönüşüm yaklaşımımızın detayları hizmetlerimiz sayfasında.