İnsan-agent ekipleri için sprint planlaması, yürütme hızına göre değil, inceleme kapasitesine göre planlama yaptığınızda işler. Agent'lar, gözden geçirenlerinizin kabul edebileceğinden daha fazla Task'ı alıp bitirebilir; dolayısıyla bir döngüdeki gerçek sınır, ne kadar kod yazıldığı değil, bir kişinin kaç tamamlanmış değişikliği inceleyip birleştirebileceğidir. Bu rehber, planlama yöntemini adım adım ele alıyor, her adımdaki başarısızlık modunu adlandırıyor ve bir sonraki Sprint'inizden önce uygulayabileceğiniz bir kontrol listesiyle bitiyor.
Klasik sprint planlaması, kıt kaynağın mühendislerin kod yazmak için harcadığı saatler olduğunu varsayar. Kodlama agent'larını eklediğinizde bu varsayım çöker. Claude Code, Codex ve Gemini CLI, siz hâlâ bir öncekini okurken bir Task'ı alıp çalışan bir diff döndürebilir. Yürütme artık darboğaz olmaktan çıkar. Kabul süreci olur.
Bu değişim, normal bir planı sessizce bozar. İki haftalık bir döngüyü geliştirici-gününe göre boyutlandırırsınız, agent'lar backlog'u üç günde tüketir ve tamamlanmış ama incelenmemiş değişikliklerden oluşan bir kuyruk, merge'ü kabul edebilen bir ya da iki kişinin arkasında birikir. Sprint hızlı görünür, yavaş biter.
Sharkly, bu rehberin içinde planlama yaptığı çalışma alanıdır. Kodlama agent'larınız zaten var; Sharkly, her Task'ı, ilerlemesini, engellerini, sonuçlarını ve insan incelemesini terminallere dağılmak yerine tek bir paylaşılan yerde tutarak onları bir ekibe dönüştürür. Sharkly'de bir Sprint, tek bir Space'e ait, zamanla sınırlı bir Task kümesidir. Aşağıdaki yöntem, ister beyaz tahtada ister ürünün içinde uygulayın aynıdır; ancak iş paylaşılan bir panoya döndüğünde başarısızlık modlarını yakalamak daha kolaydır.
Agent'lar yürütmeyi üstlendiğinde ne değişir
İnsan-agent ekipleri için sprint planlaması, bir döngüyü ekibin ne kadar kod üretebileceğine göre değil, bir insanın ne kadar tamamlanmış agent işini inceleyip kabul edebileceğine göre kapsamlandırma pratiğidir.
Agent'lar araştırır, yürütür, test eder ve raporlar. İnsanlar yön belirler, yetki verir ve sonucu kabul eder. Bütün planlama sorunu bu iş bölümüdür. Agent'larınızın verimi esnektir: üç ya da on tane çalıştırabilirsiniz. İnceleme veriminiz ise bir diff'i okuyabilen, değişikliği çalıştırabilen ve yayına hazır olduğuna karar verebilen kişi sayısıyla sabittir. Agent çıktısındaki 5 katlık bir artışın neden nadiren 5 kat daha fazla sevk edilmiş iş anlamına geldiğini görmek için inceleme kapasitesi hesabına bakın.
Yani planlarken kullanacağınız ilk sayı story point değil. İnceleme slotlarıdır: her gözden geçirenin günde kaç tamamlanmış Task'ı kabul edebileceği, çarpı gözden geçiren sayısı, çarpı döngüdeki gün sayısı. Diğer her şey bu tavanın altına sığmak zorundadır.
Sprint'i adım adım planlayın
1. Önce inceleme tavanını belirleyin. Bir gözden geçirenin günde gerçekten kabul edebileceği tamamlanmış Task sayısını tahmin edin; önemsiz olmayan bir değişikliğin gerçek incelemesi 30 ila 60 dakika sürer. Gözden geçiren sayısı ve Sprint gün sayısıyla çarpın. Başarısızlık modu: bunu atlayıp agent kapasitesine göre plan yapmak, fazla taahhüt vermek ve döngüyü Sprint'in kendisinden daha uzun bir inceleme kuyruğuyla bitirmek.
2. Task'ları yürütmeye değil incelemeye göre boyutlandırın. İşi, her Task'ın bir kişinin kafasında tutabileceği bir diff üreteceği şekilde bölün. Başarısızlık modu: bir agent memnuniyetle dokuz dosyaya yayılmış 2.000 satırlık bir değişiklik döndürür, kimse bunu tek bir slotta kabul edemez ve panonun dibinde çürür.
3. Kabul kriterlerini atamadan önce yazın. Her Task'ın test edilebilir bir "bitti" tanımına ihtiyacı vardır: ne inşa edilecek, "doğru" neye benzer, neye dokunulmayacak. Başarısızlık modu: belirsiz kapsam, agent'ın tahmin yürütmesine yol açar, gözden geçiren geri gönderir ve tek bir Task iki inceleme slotunu yakar.
4. Bilinçli olarak tek bir Agent'a veya bir Crew'ye atayın. Küçük, iyi tanımlanmış işler için tek bir Agent kullanın. Lider bir Agent'ın hedefi yorumlaması, diğer üyeleri dahil etmesi ve sonuçlarını tek bir Task'ta toplaması gerektiğinde bir Crew kullanın. Başarısızlık modu: önemsiz işlerde Crew'ye uzanmak, sonra incelemeniz gereken ek hareketli parçalar ekler.
5. Devam eden işe sınır koyun. Kanban'da WIP limitlerinin işlediği gibi, "incelemede" sütununda kaç Task'ın bekleyebileceğine bir sınır koyun. Başarısızlık modu: sınır yoksa agent'lar inceleme sütununu insanların boşaltabileceğinden daha hızlı doldurur; darboğaz son güne kadar görünmez kalır.
6. Bir esneklik payı bırakın. Yeniden çalışma ve geri göndereceğiniz değişiklik talepleri için inceleme slotları ayırın. Başarısızlık modu: %100'e plan yaparsanız ilk "lütfen düzelt" turunun inecek yeri kalmaz.
Bir elektronik tablo veya yalnızca ticket kurulumunun ölçeklenmeyi bıraktığı yer
İlk Sprint'i bir elektronik tabloda yürütebilirsiniz. Bir Task sekmesi, bir sahip sütunu, bir durum sütunu. Tek bir kişi tek bir repo üzerinde iki agent çalıştırdığı sürece bu düzen ayakta kalır.
Yürütme ile takip birbirinden ayrıldığı anda işlemez hale gelir. Agent'ın çalışması, diff, test çıktısı ve tartışma bir terminalde yaşar; elektronik tabloda ise eskimiş bir "devam ediyor" durur. Ya birileri satırı elle günceller ya da kimse güncellemez. İkinci bir repo üzerinde üçüncü bir agent eklediğinizde pano bir gün içinde gerçeklikten kopar. Sonra planlamanın bağlı olduğu tek soruyu yanıtlayamazsınız: ne bitti ve ne bana bakıyor?
Bunun için tasarlanmış bir görev panosu, yürütme ile kaydı bir arada tutar. İş, ilerleme, engeller ve sonuçlar özel oturumlarda kaybolmak yerine Task'a geri döner. Sharkly'de bir Agent hazır bir Task'ı üstlenir, paralel değişikliklerin çakışmaması için izole bir worktree'de çalışır ve değişiklik özeti, doğrulama sonuçları ve bilinen sınırları bir kişinin kabul edip geri gönderebilmesi için Task zaman çizelgesine döner. Sizin sürdürdüğünüz bir durum ile kendini sürdüren bir durum arasındaki fark budur. Bu aynı zamanda bir sonraki planlama oturumunuza gerçek veri kazandırır: agent'ların geçen döngüde hangi işi tamamladığı ve inceleme süresinin nereye gittiği.
Dürüst sınır: tek bir repo üzerinde tek bir agent çalıştırıp işi yaparken inceliyorsanız, bunun için bir görev panosuna veya Sharkly'ye ihtiyacınız yok. Tek bir terminal ve bir kontrol listesi yeterlidir. Denklem, birden fazla agent, Task, repo veya kişi üzerinden planlama yapmaya başladığınızda değişir; elektronik tablonun ikinci bir işe dönüştüğü nokta tam da burasıdır. Sharkly bu ikinci durum için tasarlandı; elektronik tablo size yalan söylemeye başladığında indirin.
Bir sonraki Sprint'inizden önce uygulayacağınız kontrol listesi
Planı onaylamadan önce bunu uygulayın:
- [ ] İnceleme tavanını hesapladınız (gözden geçirenler x günlük kabul sayısı x gün sayısı) ve bunu Sprint'in gerçek kapasitesi olarak ele aldınız.
- [ ] Her Task, tek bir slotta incelenebilecek kadar küçük.
- [ ] Her Task'ın test edilebilir kabul kriterleri ve net bir "dokunma" sınırı var.
- [ ] Her Task bilinçli olarak tek bir Agent'a veya bir Crew'ye atandı, varsayılan olarak değil.
- [ ] "İncelemede" sütununda bir WIP sınırı var.
- [ ] Yeniden çalışma ve değişiklik talepleri için pay ayrıldı.
- [ ] Her Task için merge ve yayın kararı bir insana ait.
- [ ] İlerleme, engeller ve sonuçlar özel terminallere değil paylaşılan bir panoya dönüyor.
Sekizini de işaretlerseniz agent yürütmesi, ekibin bitirebileceği bir planın içinde kalır. İlkini kaçırırsanız geri kalanı sizi kurtarmaz.
SSS
Kodu büyük ölçüde agent'lar yazdığında sprint planlaması hâlâ işe yarar mı? Evet, ama kısıt yer değiştirir. Bir Sprint artık mühendislik saatleri için bir kap değil, inceleme ve kabul için bir kap haline gelir. Döngüyü insanların ne kadar tamamlanmış işi inceleyebileceğine göre planlayın, agent'lar onu doldurur. Scrum Guide töreni hâlâ tanımlar; değişen tek şey kapasite hesabıdır.
İnsan-agent ekibi için kapasiteyi nasıl tahmin ederim? Agent'lardan değil, gözden geçirenlerden başlayın. Bir kişinin günde dürüstçe kabul edebileceği tamamlanmış Task sayısını hesaplayın, sonra gözden geçiren sayısı ve Sprint gün sayısıyla çarpın. Agent sayısı yalnızca bu tavanı aşana kadar önemlidir; sonrasında daha fazla agent sadece kuyruğu büyütür.
Agent'lar Sprint sırasında kendi Task'larını seçmeli mi? Halihazırda kabul kriterlerini taşıyan hazır Task'ları üstlenmelerine izin verin; böylece paralel işler bir dağıtıcı olmadan ilerler. İnsanları yön, yetki ve merge üzerinde tutun. Bu, insanı döngüde muhakemenin gerektiği yerde tutar ve geri kalan her yeri otomatikleştirir.
Bunun normal proje yönetiminden farkı nedir? Törenler aynı görünür; darboğaz aynı değildir. AI agent proje yönetimi, yürütme artık kıt kaynak olmadığı için geliştirici müsaitliği yerine inceleme verimi ve değişiklik izolasyonu etrafında planlama yapar.
Yeni bir araca ihtiyacım var mı, yoksa Jira'yı genişletebilir miyim? Ekibinizin zaten anladığı sistemi koruyabilirsiniz. Eksik olan nokta, ticket araçlarının bir makinenin yürüttüğü yürütmeyi değil, bir insanın yazdığı durumu takip etmesidir. Bu açığın nerede can yakmaya başladığını görmek için insan-agent ekipleri için Jira alternatiflerine bakın.
