AI destekli Sprint Planlama: sorumluluğu kaybetmeden hazırlığı nasıl hızlandırabilirsiniz

Bu, AI'ın çapraz fonksiyonlu geliştirme ekibinin klasik toplantılarını nasıl değiştirdiğine dair serinin ikinci makalesi. İlk makalede Backlog İyileştirme konusunu ele aldım ve ana sonuca vardım: AI, ekibin anlaşmasının kendisini değil, ona yönelik malzemenin hazırlanmasını hızlandırıyor. Şimdi bir sonraki adıma — Sprint Planlamaya — geçmek ve ekibin sprintin hedefi, kapsamı ve gerçekçiliği konusundaki sorumluluğunu kaybetmeden ona hazırlığı nasıl hızlandırabileceğimize bakmak mantıklı.

İlk bakışta, iyi bir iyileştirmeden sonra planlamanın neredeyse teknik bir formaliteye dönüşmesi gerekiyormuş gibi görünüyor. Backlog öğeleri zaten netleştirilmiş, kabul kriterleri taslak halinde yazılmış, riskler not edilmiş, açık sorular kısmen kapatılmış, teknik yaklaşım seçenekleri hazırlanmış. Geriye sadece görevleri sprinte seçmek ve insanlara dağıtmak kalıyor.

Ama asıl tuzak tam da burada.

Scrum'da Sprint Planlama, görev dağıtım toplantısı değildir. Bu, ekibin üç daha önemli soruya yanıt verdiği bir etkinliktir: bu sprint neden değerli, sprint boyunca gerçekte ne yapılabilir ve seçilen iş nasıl gerçekleştirilecek. Ve AI'a bu çerçeveden bakıldığında asıl şey görünür hale geliyor: AI gerçekten ekibin plan seçeneklerini daha hızlı toplamasına, bağımlılıkları vurgulamasına, bir ayrıştırma önermesine ve soruları hazırlamasına yardımcı olabilir. Ancak Sprint Hedefi sorumluluğunu üstlenemez ve planı tek başına gerçekçi kılamaz.

“AI, gerçekçi görünen bir plan oluşturmaya yardımcı olur. Onu gerçekçi kılan ise yalnızca ekiptir.”

Bence asıl değişim tam da burada. AI, Sprint Planlamaya hazırlığı hızlandırır, ancak Sprint Planlamanın kendisini — hedef, kapsam ve teslimat yöntemi konusunda ekip anlaşmasını — ikame etmez.

Sprint Planlama neden sadece “sprinte görev doldurmak” değildir

Scrum Rehberi 2020'de Sprint Planlama, sprinti başlatan etkinlik olarak tanımlanır. Çıktısı, tüm Geliştirme Ekibinin ortak çalışmasıyla oluşturulur.

Sprint Planlama üç tema etrafında şekillenir

• Bu sprint neden değerli?
• Bu sprintte ne yapılabilir?
• Seçilen iş nasıl gerçekleştirilecek?

Bu önemli bir sıralamadır. Önce görev listesi değil, değer gelir. “Neyi kapatabiliriz” değil, “sprint sonunda hangi değişimi elde etmek istiyoruz”. Bu nedenle Sprint Hedefi, Jira'daki dekoratif bir satır ya da seçilen görevlerin güzel bir kısa özeti değildir. Bu, sprintin tek hedefidir; yani ekibe odak sağlayan ve sprint içinde yeni olgular ortaya çıktığında karar almayı mümkün kılan tek hedeftir.

Sprint Backlog bu durumda üç bölümden oluşur: “neden” olarak Sprint Hedefi, “ne” olarak seçilen backlog öğeleri ve “nasıl” olarak uygulanabilir plan. Ve özellikle önemli olan, Sprint Backlog'un geliştiriciler tarafından ve geliştiriciler için oluşturulmuş bir plan olmasıdır. Ürün Sahibi tartışmanın hazırlanmasına ve seçilen işin Ürün Hedefiyle ilişkilendirilmesine yardımcı olur, Scrum Master etkinliğin faydalı ve verimli olmasına yardımcı olur, ancak uygulama planı ve mühendislik kısmının gerçekçiliğine ilişkin sorumluluk geliştirme ekibinin içinde kalır.

Bundan, AI hakkında konuşmak için basit ama çok önemli bir sonuç çıkar: araç bir Sprint Hedefi ifadesi, ön backlog öğeleri listesi, bağımlılıklar, riskler ve ayrıştırma önerebilir. Ancak ekip taahhüdünün taşıyıcısı olamaz. Ekip adına “bunu gerçekten üstlenmeye hazırız” diyemez.

AI'ın planlamada gerçekte neyi değiştirdiği

Hemen kanıt sınırını belirteyim. Bugün gerçek Scrum ekiplerinde AI destekli Sprint Planlama üzerine güçlü bir araştırma temeli az. Komşu konularda çok daha fazla çalışma var: gereksinim mühendisliği, kullanıcı hikâyelerinin kalitesi, efor tahmini, test üretimi, insanın AI ile birlikte karar alması ve AI risk yönetimi. Bu nedenle “AI sprinti planlıyor” değil, “AI tartışılacak taslak planın toplanmasını hızlandırıyor ve ekibin bazı boşlukları daha erken görmesine yardımcı oluyor” demek daha doğru. Bu önemli bir fark.

AI ortaya çıkmadan önce Sprint Planlamaya hazırlık çoğu zaman oldukça manueldi. Ürün Sahibi önceden öncelikleri inceler ve ön çalışma kapsamını toplamaya çalışırdı. Analist, backlog öğelerinin tartışmaya ne kadar hazır olduğunu kontrol ederdi. Geliştiriciler teknik kısıtları ve benzer görevleri hatırlardı. QA test risklerini gündeme getirirdi. Scrum Master, toplantının daha önce açıklığa kavuşturulması gereken ayrıntılar hakkında kaotik bir tartışmaya dönüşmemesini gözetlerdi.

AI ile bu hazırlık katmanı belirgin şekilde daha hızlı hale gelebilir — takımın kaliteli bir girdi bağlamı ve sonucu doğrulamak için anlaşılır bir süreci olması koşuluyla. Model birkaç Sprint Goal varyantı oluşturmaya, backlog öğelerini hedef etrafında gruplamaya, kabul kriterlerindeki zayıf noktaları vurgulamaya, bağımlılık listesi önermeye, geçmişte benzer görevleri bulmaya, riskleri taslak halinde çıkarmaya ve QA, backend, frontend ve tasarım için sorular hazırlamaya yardımcı olabilir. Ancak bu, nihai planning'in her zaman daha hızlı veya daha doğru olacağının kanıtı değildir: kazancın bir kısmı insan doğrulamasına, kaynakların kontrolüne ve taslağın hatalarının düzeltilmesine gidebilir.

Bu özellikle takım planning'e AI destekli refinement sonrasında geldiğinde faydalıdır. Önceki makalede AI'ın ham bir talebi daha olgun bir backlog öğesine dönüştürmeye daha hızlı yardımcı olduğunu göstermiştim. Ama şimdi bir sonraki soru ortaya çıkıyor: backlog öğeleri daha iyi görünmeye başladıysa, bu planın da daha iyi olduğu anlamına gelir mi?

Mutlaka değil.

AI planning artefaktlarını daha düzenli hale getirebilir. Her şey zaten bağlantılıymış hissi yaratabilir: işte Sprint Goal, işte iş kapsamı, işte riskler, işte bağımlılıklar, işte test notları. Ama bu henüz bir plan değil. Bu bir plan taslağı. Ve Sprint Planning'in değeri tam olarak takımın bu taslağı gerçeklik açısından doğrulamasındadır.

AI, Sprint Goal varyantlarını, iş kapsamını, bağımlılıkları ve riskleri daha hızlı toplamaya yardımcı olur, ancak planın gerçekçiliğinin takım tarafından doğrulanmasının yerini almaz.

Aynı vakaya devam edelim: B2B LMS ve email hatırlatmaları

Soyut konuşmamak için ilk makaledeki vakaya devam edeceğim.

Kurumsal eğitim için bir B2B LMS platformu var. Büyük müşteriler çalışanlarına compliance, güvenlik ve iç düzenlemelerle ilgili zorunlu kurslar atıyor. İş tarafı, zorunlu kursu son tarihe kadar tamamlamayan çalışanlara otomatik email hatırlatmaları eklemek istiyor.

Refinement'ta takım görevin sadece görünüşte basit olduğunu zaten ortaya çıkarmıştı. Aslında şunlar üzerinde anlaşmak gerekiyor:

• kimin hatırlatma koşullarına uygun sayılacağı;
• yalnızca zorunlu kursların mı alınacağı;
• hangi durumların dikkate alınacağı: not_started, in_progress, expired;
• nasıl hariç tutulacağı archived ve devre dışı kullanıcılar;
• saat diliminin nerede saklandığı;
• dil ayarının ve dil fallback'inin nasıl çalıştığı;
• zamanlayıcı görevi yeniden çalıştığında yinelenenlerden nasıl korunulacağı;
• geçmiş / denetim kaydının gerekli olup olmadığı;
• müşteri destek ekibinin neyi görebilmesi gerektiği;
• ilk sürümün minimum iş kapsamının nerede bittiği.

İyi bir refinement sonrasında takım Sprint Planning'e zaten güçlü bir taslakla gelebilir. Örneğin AI, bir kullanıcı hikayesi taslağı, kabul kriterleri, sınır durumları listesi, teknik yaklaşım seçenekleri ve açık soruları toplamaya yardımcı olmuş olabilir. Ama planning'de farklı türde bir karar vermek gerekir: takımın yakın sprintte tam olarak neyi ve hangi amaçla aldığı.

Bu vaka için kötü bir Sprint Goal şöyle görünebilirdi:

“Scheduler, email hatırlatmaları ve geçmiş kaydı yapmak.”

Biçimsel olarak anlaşılır, ama bu sadece bir bileşenler listesi. Sprint'in neden değerli olduğunu, hangi minimum sonucun ortaya çıkması gerektiğini ve hangi ödünlerin kabul edilebilir olduğunu açıklamıyor.

Daha güçlü bir ifade:

“Sistem, son tarihe kadar zorunlu kursu tamamlamamış aktif çalışanlara tek bir doğru hatırlatma gönderir ve doğrulanabilir bir gönderim geçmişi saklar.”

Bu ifade daha iyi çünkü içinde zaten değer ve sınırlar var. Tam kapsamlı bir müşteri paneli vaat etmiyoruz. Karmaşık hatırlatma mantığı vaat etmiyoruz. expiredetrafındaki tüm tartışmaları hemen çözmüyoruz. Genişletilmiş analitik kurmuyoruz. Ama minimum değerli bir sonuç vaat ediyoruz: doğru çalışan doğru hatırlatmayı alıyor ve takım mektubun kime, ne zaman ve neden gittiğini doğrulayabiliyor.

Planning AI olmadan nasıl görünürdü

AI olmadan böyle bir toplantı sıklıkla bağlamı yeniden kurmakla başlar. Ürün sahibi iş talebini hatırlatır. Analist refinement'ta neyin ortaya çıkarıldığını özetler. Backend bildirim servisinin nasıl çalıştığını netleştirir. Frontend bir ayarlar ekranının gerekli olup olmadığını ya da backend mantığının yeterli olup olmadığını sorar. QA son tarihler, saat dilimleri, yinelenenler ve durumlar hakkında soruları çıkarmaya başlar. Tasarımcı ilk iş kapsamında hiç UI olup olmadığını anlamaya çalışır.

Toplantının yarısı gerçekçi bir plan seçmeye değil, materyali takımın zihnine yeniden kaldırmaya gider. Bir noktada basitçe “önemli olan her şeyi alalım” cazibesi ortaya çıkar: koşullara uygunluk, scheduler, email şablonu, tekilleştirme / yinelenenlerin giderilmesi, geçmiş kaydı, dil fallback ayarı, saat dilimi, müşteri destek ekibi için bilgi görünürlüğü, expired, işlenmesi, müşteri ayarları ve birkaç sınır durumu daha.

Böyle bir iş hacmi sağduyu düzeyinde makul görünebilir: sonuçta her şey birbiriyle bağlantılı. Ama tam da burada planning şişmeye başlar. Ekip sanki bütünsel bir sonuçtan bahsediyor, ama gerçekte birbirinden bağımsız birkaç belirsizlik yönü topluyor. Bir yerde ürün semantiği belirsiz, bir yerde teknik uygulama, bir yerde test, bir yerde UI, bir yerde destek.

Sonuç olarak toplantının sonunda eksiksiz görünen ama kırılgan kalan bir Sprint Backlog ortaya çıkabilir. Bu, tüm tartışmalı noktaların sprint boyunca çözüleceği umuduna dayanır. Bazen böyle olur. Ama çoğu zaman ekip tam da bu şekilde tamamlanmamış işin devredilmesini, iş hacminin gizli şekilde yayılmasını ve hoş olmayan bir hissi elde eder: “sonuçta her şeyi konuşmuştuk”.

Planning AI ile nasıl değişir

AI ile aynı toplantı başka bir düzeyde başlayabilir.

Planning'den önce AI, Ürün Sahibinin birkaç Sprint Goal varyantı hazırlamasına yardımcı olur: dar bir ilk sürüm, daha geniş bir müşteri iş hacmi, teknik olarak güvenli iş hacmi, genişletilmiş iddialı hacim. Analist AI'dan backlog öğelerini her hedef varyantıyla ilişkilendirmesini ve hangilerinin hedefi doğrudan desteklemediğini göstermesini ister. Backend, bildirim mimarisi açıklamasını AI üzerinden çalıştırır ve planlayıcı, tekilleştirme ve idempotentlik görevlerinin risklerini vurgulamasını ister. Frontend ve tasarımcı, ilk sprintte UI'ın gerekli olup olmadığını yoksa minimal geçmiş gösterimiyle sınırlı kalınabileceğini kontrol eder. QA, AI'dan negatif senaryolar, sınır senaryoları ve zamana bağlı senaryoların bir listesini hazırlamasını ister.

Ekip planning'e boş bir sayfayla değil, bir dizi varyantla gelir:

• asgari iş hacmi: zorunlu kurslar, not_started / in_progress, arşivlenmiş ve devre dışı bırakılmış kullanıcıların hariç tutulması, tek hatırlatma, yinelenenlerin giderilmesi, geçmiş günlüğü;
• genişletilmiş iş hacmi: artı dil fallback ayarı ve daha dikkatli saat dilimi politikası;
• genişletilmiş iddialı hacim: artı müşteri destek ekibi için görünürlük;
• iş hacmi dışında: expired, karmaşık periyodiklik kuralları, genişletilmiş analitik, müşteri bazında bireysel programlar.

Bu, bilişsel işi büyük ölçüde azaltır. Artık ekip toplantının büyük bölümünü varyantları ilk kez formüle etmekle geçirmiyor. Hangi varyantın gerçekçi olduğunu, hangisinin Sprint Goal'ü daha iyi desteklediğini ve hangi risklerin örtük bırakılamayacağını tartışıyor.

Ama tam da burada yeni bir tuzak ortaya çıkar. AI tarafından derlenen plan o kadar düzgün görünebilir ki ekip onu kontrol etmeye değil, düzenlemeye başlar. “Bunu gerçekten yapabilir miyiz?” diye sormaz, yalnızca ifadeleri iyileştirir. Ekibin mevcut kapasitesi hakkında tartışmaz, güzel ayrıştırmaya güvenir. Bağımlılıkları kontrol etmez, tabloya girdilerse zaten hesaba katıldıklarını varsayar.

Ve o zaman AI planning'e yardımcı olmaz. Sadece aşırı iyimser planı daha ikna edici hale getirir.

Ana tuzak: planın yanlış gerçekçiliği

Refinement'ta ana risk yanlış netlikti: görev anlaşılır görünür çünkü AI onu güzelce biçimlendirmiştir. Sprint Planning'de risk farklıdır — yanlış gerçekçilik.

Yanlış gerçekçilik, plan tutarlı, eksiksiz ve mantıklı göründüğünde, ama ekibin gerçek kısıtlarına karşı kontrol edilmediğinde ortaya çıkar. Bir Sprint Goal'ü, görev listesi, tahminler, bağımlılıklar ve riskler vardır. Ama kimse ekibin mevcut kapasitesinin yeterli olup olmadığını, önceki sprintten tamamlanmamış iş olup olmadığını, QA'nın aşırı yüklenip yüklenmediğini, gerekli uzmanın müsait olup olmadığını, Definition of Done'a gerçekten ulaşılıp ulaşılamayacağını ve en zor kısmın “entegre etmek”, “destek eklemek” veya “sınır durumları hesaba katmak” sözcükleri altında saklanıp saklanmadığını gerçekten kontrol etmemiştir.

Bu risk birkaç bilinen sorunla iyi örtüşür.

Birincisi — planlama yanlılığı. Ekipler zaten gelecekteki işin karmaşıklığını küçümseme eğilimindedir, özellikle plana “içeriden” bakıp istenen senaryoya odaklandıklarında. AI, geçmiş verileri, benzer görevleri, önceki gecikmeleri ve tamamlanmamış işin devredilmesinin tipik nedenlerini ortaya koyarsa yardımcı olabilir. Ama pürüzsüz, ikna edici bir hikâye yaratırsa planlama yanlılığını güçlendirebilir de: “her şey tutarlı görünüyor, o halde her şey gerçekçi”.

İkincisi — otomasyon yanlılığı. Sistem düzgün bir plan önerdiğinde, insanın aktif doğrulama modundan pasif onaylama moduna geçmesi daha kolaydır. Ekip artık aktif olarak çelişki aramaz, çünkü “AI her şeyi toplamıştır”. Bu özellikle planning'de tehlikelidir, çünkü kararın kalitesi metnin eksiksizliğine değil, kısıtların dürüstçe tartışılmasına bağlıdır.

Üçüncüsü — model halüsinasyonu veya konfabülasyon / kendinden emin uydurma. AI, var olmayan bir bağımlılığı kendinden emin şekilde uydurabilir. Ya da aslında yalnızca yüzeysel olarak benzer olan “benzer bir göreve” atıfta bulunabilir. Ya da durumlar, saat dilimi, dil fallback ayarı veya mimari kısıt hakkında yanlış bir sonuca varabilir. Sorun bu tür hataların her zaman kaba olması değildir. Aksine, en tehlikeli hatalar inandırıcı görünür.

Dördüncüsü — yalancı kesinlik. AI güzel bir tahmin, düzgün bir aralık veya kendinden emin bir adım dizisi sunduğunda, ekipte kesinlik hissi oluşabilir. Ancak planlamanın kesinliği iyi bir tablodan doğmaz. Çevik efor tahmini üzerine araştırmalar, tahminlerin kalitesinin birçok faktöre bağlı olduğunu gösteriyor: ekibin deneyimi, önceki deneyim, görevlerin büyüklüğü, bilginin kalitesi, tahmin pratiği, proje yönetimi ve iş etkileri. Bu nedenle AI'ın tek başına "tahminleri iyileştirdiğini" yazmak veya düşünmek tehlikelidir. Daha dürüst bir ifade: AI eksik bilgiyi, benzer durumları ve istikrarsız varsayımları ortaya çıkarmaya yardımcı olabilir, ancak tahmini yine de ekip doğrulamalıdır.

Bu nedenle Sprint Planning'de AI'ın olgun kullanımı "bize nasıl bir plan oluşturdu?" sorusuyla değil, "bu planda ne yanlış, eksik veya fazla pürüzsüz olabilir?" sorusuyla başlar. İyi bir ekip yalnızca AI taslağını iyileştirmez, özellikle onu çürütmeye çalışır: kaynakları, varsayımları, bağımlılıkları, ekibin mevcut kapasitesini, Definition of Done'ı ve modelin olguların izin verdiğinden daha fazlasını kendinden emin biçimde genellemiş olabileceği yerleri kontrol eder.

Rollere göre neler değişiyor

Ürün Sahibi

Ürün Sahibi AI ile Sprint Goal ve iş kapsamı seçeneklerini daha hızlı elde eder. Modelden birkaç senaryo göstermesini isteyebilir: minimum, güvenli, iddialı, stretch. Hangi backlog öğelerinin gerçekten hedefi desteklediğini, hangilerinin sadece "onlar da faydalı" olduğunu daha hızlı görebilir.

Ancak Ürün Sahibi'nin sorumluluğu ortadan kalkmaz. Aksine daha görünür hale gelir. AI bağlantılı görünen her şeyi sprinte almayı önerirse, Ürün Sahibi değer sorusunu tutmalıdır: kullanıcı veya paydaş için gerçekten gereken minimum sonuç nedir? Şimdi ne yapılmayabilir? Neyi ertelemek Sprint Goal'ı bozar, ne sadece hoş olur?

İş Analisti

Analist için AI, tutarlılık kontrolü aracı olarak faydalıdır. Kabul kriterlerindeki boşlukları, backlog öğeleri arasındaki çelişkileri, örtük varsayımları ve planning'de gündeme getirilmesi gereken soruları hızla bulmaya yardımcı olur.

Ancak analist, biçimsel olarak güzel bir gereksinimi fiilen doğrulanmış olandan ayıran kişi olarak kalır. LMS vakasında "tamamlanmamış kurs"un apaçık bir terim olmadığını fark etmesi gereken kişi tam da analisttir. Bunlar belirli durumlar, istisnalar, son tarihler, müşteri kuralları ve sistemdeki verilerdir.

Backend Geliştirici

Backend, AI'dan teknik riskler üzerine hızlı bir ilk geçiş alır: zamanlayıcı görevleri, idempotentlik, tekilleştirme anahtarı, denetim günlüğü, yeniden deneme mantığı, bildirim servisiyle entegrasyon. Bu, hazırlığı hızlandırır.

Ancak AI, gerçek mimarinin tamamını ekibin bildiği gibi bilmez. Legacy kısıtları, istikrarsız kuyruğu, veri özelliklerini veya servisler arası anlaşmaları hesaba katmayan makul bir şema önerebilir. Bu nedenle backend, AI'ın teknik ayrıştırmasını "kabul etmemelidir". Onu eleştirmelidir.

Frontend Geliştirici

Frontend, ilk iş kapsamında UI'ın gerekip gerekmediğini, hangi durumların gösterilmesi gerektiğini, kullanıcının gönderim geçmişini nasıl göreceğini, ayar yönetiminin gerekip gerekmediğini veya salt okunur görünürlüğün yeterli olup olmadığını daha hızlı kontrol edebilir.

Ancak planning dürüstçe yanıtlamalıdır: UI gerçekten Sprint Goal için gerekli mi, yoksa bu zaten bir genişleme mi? Hedef, hatırlatmayı doğru şekilde göndermek ve doğrulanabilir bir geçmiş saklamaksa, ilk sprinte tam bir istemci arayüzü gerekmiyor olabilir. AI seçenekleri formüle etmeye yardımcı olabilir, ancak uzlaşmayı ekip kabul etmelidir.

Kalite Mühendisi / QA Mühendisi

QA, AI'dan göründüğünden daha fazla yararlanıyor olabilir. Model hızla negatif senaryolar, sınır senaryoları, zamana bağlı senaryolar, saat dilimi kontrolleri, dil fallback'i, arşivlenmiş ve devre dışı bırakılmış kullanıcılar, zamanlayıcı görevinin yeniden çalıştırılması ve yinelenenlerin giderilmesi üretir.

Ancak ekibi yalancı kapsamdan koruması gereken tam da QA'dır. Uzun bir test fikri listesi, planın test edilebilir olduğu anlamına gelmez. Plan ancak kabul kriterleri açık, veriler erişilebilir, gözlemlenebilirlik anlaşılır ve ekip Definition of Done'ın karşılandığını nasıl kanıtlayacağını biliyorsa test edilebilir.

UX/UI Tasarımcısı

Tasarımcı AI ile UI yaklaşımı seçeneklerini daha hızlı toplar: hatırlatma ayarları, gönderim geçmişi, hata durumları, müşteri destek ekibi için ipuçları. Ancak planning'deki görevi, iş kapsamını güzel arayüz özellikleriyle genişletmek değil, gerekli olanı arzu edilenden ayırmaya yardımcı olmaktır.

Bizim vakamızda tam bir dashboard faydalı olabilir, ancak ilk Sprint Goal için zorunlu değildir. Tasarımcı, değer kaybı olmadan kullanıcı yolunu daraltmaya yardımcı olursa planın gerçekçiliğini artırır.

Scrum Master

Scrum Master, AI destekli planlamada artık "toplantı düzenleyicisi" değil, ekip taahhüdünün kalitesinin koruyucusudur. Görevi, AI taslağının kendi başına bir otorite haline gelmemesini sağlamaktır.

Burada iyi Scrum Master soruları şöyle seslenir:

• Bu sprinte neden değerli olduğunu gerçekten anlıyor muyuz?
• Geliştiriciler bu Sprint Backlog'u kendi planları olarak görüyor mu?
• AI taslağında neyi olgularla doğruladık?
• Plan nerede fazla pürüzsüz görünüyor?
• Yeni bilgi ortaya çıkarsa ilk olarak neyi kaldırırız?
• Sprint Goal bir görev listesine dönüşmedi mi?

Karşılaştırma: AI olmadan ve AI ile Sprint Planning

Planlama alanı	AI olmadan	AI ile ne değişiyor
Sprint Goal	Canlı tartışmada, bazen görevler seçildikten sonra formüle edilir	AI hızlıca birkaç hedef varyantı önerir
İş kapsamının seçimi	Ekip backlog öğelerini sırayla tartışır ve sıklıkla sınırlar üzerine tartışır	AI kısa bir liste, alternatif kapsam varyantları ve kapsam dışı öneriler derler
Ekibin kullanılabilir kapasitesi	Kişiler, izinler, destek ve tamamlanmamış işin devri üzerinden manuel hesaplanır	AI geçmiş sinyalleri ve takvim kısıtlarını derleyebilir
Bağımlılıklar	Ekibin hafızası ve deneyimi aracılığıyla ortaya çıkar	AI metinden ve geçmişten ön bağımlılıkları daha hızlı çıkarır
Ayrıştırma	Geliştiriciler işi kendileri böler	AI ayrıştırmayı daha hızlı ve ayrıntılı önerir
Test	QA kritik senaryoları manuel olarak ortaya çıkarır	AI ön negatif ve sınır senaryo varyantları üretir
Risk yönetimi	Riskler sıklıkla parçalı olarak dile getirilir	AI hızlıca bir risk listesi ve varsayım kaydı oluşturur
Ekip taahhüdü	Tartışma sonrası ekip mutabakatından doğar	AI kabul edilmesi daha kolay, cilalı bir plan oluşturur
Dokümantasyon	Sıklıkla toplantı sonrası elle tamamlanır	AI kararları, varsayımları ve sonraki adımları hızlıca kaydeder

Yeni riskler ve manuel olarak neyin kontrol edilmesi gerektiği

Planlama alanı	Yeni risk	Manuel olarak ne kontrol edilmeli
Sprint Goal	Sprint Goal, iş kapsamının güzel bir kısa özetine dönüşür	Hedefte yalnızca “ne yapıyoruz” değil, “neden” var mı
İş kapsamının seçimi	Yanlış bütünlük ve iş kapsamının aşırı sıkıştırılması	Her öğe gerçekten Sprint Goal için gerekli mi? İlk olarak ne kaldırılabilir?
Ekibin kullanılabilir kapasitesi	Gerçek dikkat dağıtıcıların, hataların, desteğin ve toplantıların atlanması	İzinler, destek yükü, tamamlanmamış iş, zorunlu toplantılar ve dış bağımlılık beklemeleri dikkate alındı mı
Bağımlılıklar	Model var olmayan bir bağımlılık uydurabilir veya organizasyonel bir bağımlılığı atlayabilir	Tüm dış bağımlılıklar insanlar tarafından doğrulandı ve sorumluları var
Ayrıştırma	Ekip başkasının bölme mantığını pasif olarak kabul eder	Bölme, ekibin mimarisini, risklerini ve Definition of Done'ını yansıtır
Test	Sahte kapsama: çok test var ama başarısızlık modları yok	Doğrulanabilir kabul kriterleri, gözlemlenebilirlik ve test verileri var mı
Risk yönetimi	Liste eksiksiz görünür ve konuyu kapatır	Hangi riskler gerçeklerle doğrulanmadı? Hangileri şimdiden azaltılabilir?
Ekip taahhüdü	Sahiplik / sorumluluğun sulandırılması: “plan zaten derlendi”	Geliştiriciler Sprint Backlog'u kendi planları olarak açıkça onayladı
Dokümantasyon	Tutanağa anlaşmalar değil, modelin ikna edici ifadeleri girer	Tüm kilit kararlar, gerçekler ve açık sorular katılımcılar tarafından doğrulandı

Bu tablodaki ana nokta, AI'ın “planlamayı daha iyi yaptığı” değil. Daha doğru düşünce şu: AI neredeyse her yerde taslakların, listelerin, alternatiflerin ve tutanakların derlenmesini hızlandırır. Ancak neredeyse hiçbir yerde, gerçekliğe uygunluk, gerçekçilik ve sahiplik / sorumluluk açısından son insan doğrulama döngüsünün yerini almaz.

Yönetişim ve veri hijyeni: modele düşüncesizce ne verilmemeli

Planlamada sıklıkla AI'a her şeyi yükleme cazibesi doğar: Jira'daki görevler, Slack'teki tartışma dizileri, müşteri talepleri, destek kayıtları, dokümantasyon parçaları, ekip takvimi, olay geçmişi, paydaşlarla yazışmalar. Planlama kalitesi açısından bu anlaşılır: bağlam ne kadar fazlaysa taslak o kadar iyi olur.

Ancak yönetişim açısından bu tehlikelidir.

Ekip Sprint Planning hazırlığı için AI kullanıyorsa, hangi verilerin modele aktarılabileceği, hangilerinin aktarılamayacağı, sonucu kimin kontrol edeceği ve tartışmalı noktaların nasıl kaydedileceği konusunda önceden anlaşmalıdır. Burada basit bir yönetişim yaklaşımı iyi işler: sorumlu kontrolleri açıkça atamak, gerçekleri varsayımlardan ayırmak, bilinmeyenleri kaydetmek, ekibin önemli manuel geçersiz kılmalarını AI önerilerinin üzerinde tutmak ve kilit iddialar için kaynakları doğrulamak. Model için istemlere / sorgulara düşüncesizce şunlar eklenmemelidir:

• gerçek müşteri adları;
• kullanıcıların ve çalışanların e-posta adresleri;
• üretim verileri;
• güvenlik olayı ayrıntıları;
• kimlik bilgileri, tokenlar, API anahtarları;
• tam denetim kayıtları;
• hukuki belgeler ve sözleşme koşulları;
• İK bilgileri;
• planlama için gerekmeyen ticari açıdan hassas ayrıntılar.

Minimize edilmiş ve anonimleştirilmiş bağlamla çalışmak daha güvenlidir: gerçek tanımlayıcıları anonim yer tutucularla değiştirmek, hassas verileri kaldırarak düzenleme / anonimleştirme kullanmak, ham dökümler yerine toplulaştırılmış geçmiş kalıpları aktarmak, gerçekleri varsayımlardan ayırmak ve planlama hazırlığında hangi istemlerin / sorguların ve model yanıtlarının gerçekten kullanıldığını kaydetmek.

Bu bürokrasi değildir. Bu, AI destekli planlamayı bir veri sızıntısı kanalına dönüştürmemek ve modele belirli bir karar için gerekenden fazla bağlam vermemek için bir yoldur.

Kontrol listesi: AI tarafından derlenen Sprint Planı şu durumlarda tartışılabilir…

Bu kontrol listesi resmi bir Scrum artefaktı değildir. Ekibin AI taslağını gerçek planla karıştırmamasına yardımcı olan pratik bir filtredir.

AI tarafından derlenen Sprint Planı şu durumlarda tartışılabilir:

• Sprint Goal, görev listesi olarak değil, kullanıcı / paydaş için değer veya değişmiş bir durum olarak ifade edilmiştir.
• Seçilen her backlog öğesi için ekip, bunun Sprint Goal'ü nasıl desteklediğini açıklayabilir.
• Ekibin mevcut kapasitesi soyut olarak değil, izinler, destek, hata düzeltmeleri, tamamlanmamış işin devri, oryantasyon ve zorunlu toplantılar dikkate alınarak hesaplanmıştır.
• Önceki sprintten kalan tamamlanmamış iş açıkça ele alınmıştır: neyin devredildiği, neyin iptal edildiği, neyin yeniden tahmin gerektirdiği.
• Dış bağımlılıklar açıkça belirtilmiştir, her birinin bir sorumlusu ve anlaşılır bir durumu vardır.
• Seçilen kapsam için ekip, yalnızca "kod neredeyse hazır" durumuna değil, Definition of Done'a giden yolu görür.
• Plan test edilebilirdir: kabul kriterleri, negatif senaryolar, sınır senaryoları, gözlemlenebilirlik ve doğrulama için anlaşılır veriler vardır.
• Ekip, sprintin minimum değerli kapsamını tek bir cümleyle söyleyebilir.
• Ekip, yeni bilgi ortaya çıkarsa kapsamdan ilk olarak neyin çıkarılabileceğini önceden anlar.
• AI taslağındaki önemli olgusal iddialar elle doğrulanmıştır: durumlar, bağımlılıklar, geçmiş veriler, mimari kısıtlar, son tarih kuralları, yerelleştirmeler, yinelenenlerin ayıklanması.
• Katılımcılardan biri özellikle AI taslağını çürütmeye çalışmıştır, yalnızca onu iyileştirmeye değil.
• Ekip, planın nerede fazla pürüzsüz, fazla kesin veya şüphe uyandıracak kadar "kendiliğinden anlaşılır" olduğuna ayrıca bakmıştır.
• Geliştiriciler, Sprint Backlog'un kendi planları ve Sprint Goal'ün sprint için ekibin taahhüdü olduğunu açıkça onaylamıştır.
• Planning sonucu, neyin kararlaştırıldığı, neyin varsayıldığı, neyin bilinmez kaldığı ve neyin kapsam dışına alındığı açık olacak şekilde kaydedilmiştir.

Pratikte bu kontrol listesi resmi bir kontrol bariyeri olarak değil, planning sonunda kısa bir düşünme disiplini olarak kullanılabilir. Özellikle iki soru faydalıdır: "bu AI taslağında ne yanlış olabilir?" ve "gerçeklik daha karmaşık çıkarsa ilk olarak neyi çıkarırız?".

Ekibe önerim

Birincisi, AI'ı Sprint Planning'den önce "sprinti planlasın" diye değil, iyi bir insan tartışması için malzeme hazırlasın diye kullanmak. Seçenekleri, bağımlılıkları, varsayımları, riskleri, sınır durumlarını, alternatif kapsam seçeneklerini ve soruları toplasın. Ancak karar ekipte kalmalıdır.

İkincisi, plan taslağını her zaman ekip taahhüdünden ayırmak. AI taslağı mükemmel bir ön çalışma olabilir, ancak Sprint Backlog ancak Geliştiriciler onu kendi planları olarak anladığında gerçek olur.

Üçüncüsü, AI tarafından üretilen tahminleri yapısal göründükleri için daha nesnel saymamak. Otomatik değerlendirme / AI destekli efor tahmini üzerine replikasyonlar ve incelemeler dikkatli olmak için yeterli gerekçe sunar: karmaşık bir model yalnızca karmaşık olduğu için basit bir temel modelden daha iyi hale gelmez. Tahminlerde yalnızca hata değil, aşırı güven de tehlikelidir. AI'ı kesinlik yanılsaması yaratmak için değil, belirsizlikleri ortaya çıkarmak için kullanmak daha iyidir.

Dördüncüsü, kapsam dışını açıkça kaydetmek. İyi AI destekli planning oturumlarında değer çoğu zaman yalnızca ekibin seçtikleriyle değil, bilinçli olarak almadıklarıyla da yaratılır. LMS vakasında bu expired, müşteri destek ekibi için tam kapsamlı bir gösterge paneli, hatırlatma sıklığının karmaşık segmentasyonu ve gelişmiş analitik olabilir.

Beşincisi, doğrulama sahipleri atamak. İş anlamını Ürün Sahibi, gereksinim tutarlılığını analist, mimari uygulanabilirliği geliştiriciler, test edilebilirliği QA, kullanıcı deneyimi sınırlarını tasarımcı, ekip mutabakatının kalitesini Scrum Master doğrular. AI genel bir taslak hazırlayabilir, ancak doğrulamanın sahibi olamaz.

Sonuç

Backlog Refinement'ta AI tartışma malzemesini daha hızlı toplamaya ve düzenlemeye yardımcı oluyorsa, Sprint Planning'de plan seçeneklerini daha hızlı toplamaya yardımcı olur. Sprint Goal önerebilir, backlog öğelerini gruplayabilir, bağımlılıkları vurgulayabilir, bir ayrıştırma taslağı çıkarabilir, test senaryoları hazırlayabilir, varsayımları yazabilir ve hatta toplantı sonucunu güzelce kaydedebilir.

Ancak bu, planı gerçekçi kılmaz.

Gerçekçi bir Sprint Planı ancak ekip değeri, kapsamı, ekibin mevcut kapasitesini, bağımlılıkları, Definition of Done'ı, test edilebilirliği ve bunu işe alma konusundaki kendi hazırlığını dürüstçe doğruladığında ortaya çıkar. AI bu doğrulamayı hızlandırabilir, ancak yerini alamaz. Daha fazla seçenek görmeye yardımcı olabilir, ancak ekip taahhüdünü insanlar adına seçemez.

Bu nedenle AI'ın Sprint Planning'deki ana etkisini şöyle ifade ederim: plan seçeneklerini hazırlamanın maliyetini düşürür, ancak insan doğrulamasının bedelini artırır. Güzel bir plan oluşturmak ne kadar kolaysa, onun gerçek bir ekip planı olup olmadığını anlamak o kadar önemli hale gelir.

Olgun bir ekipte AI, Sprint Planning'i otomatik Sprint Backlog üretimine dönüştürmez. Onu hedef, kısıtlar ve ödünleşimler hakkında daha somut bir konuşmaya dönüştürür. Ve belki de otomasyonun en faydalı biçimi budur: insanları planning'den çıkarmak değil, dikkatlerini aracın onlar adına veremeyeceği kararlar için serbest bırakmak.

Kaynaklar ve referanslar

• Scrum Guide 2020 — Sprint Planning, Sprint Goal, Sprint Backlog, sorumluluk alanları.
• NIST yapay zeka risk yönetimi çerçevesi 1.0 — yönetişim / düzenleme, hesap verebilirlik / sorumluluk, insan-AI etkileşiminin yapılandırılması.
• NIST üretken yapay zeka profili — konfabülasyon / kendinden emin uydurma, aşırı bağımlılık, gizlilik ve risk yönetimi.
• ChatGPT as a tool for User Story Quality Evaluation — kullanıcı hikâyeleri kalitesi görevleri için orta düzeyde kanıt tabanı örneği.
• Large Language Models for Software Engineering: Survey and Open Problems — yazılım geliştirme / yazılım mühendisliğinde LLM'lere genel bakış.
• Oценка трудозатрат в Agile-разработке ПО: систематический обзор литературы — Agile tahmin kalitesinin faktörleri.
• Reasons and Approaches for Accurate Effort Estimations in Agile Iterative Development — bilgi kalitesi, ekip, tahmin pratiği, proje yönetimi, iş etkisi.
• GPT2SP replication report — story point'lerde AI tahmininin sınırlamaları ve basit temel modeller / referanslarla karşılaştırma.
• К надежному итеративному Agile-планированию через прогнозирование изменений документации рабочих элементов — dokümantasyon değişiklikleri ile planning kırılganlığı arasındaki bağlantı.
• The Planning Fallacy — sürelerin hafife alınması üzerine klasik çalışma.
• Automation Bias in Intelligent Time Critical Decision Support Systems — otomasyon yanlılığı, atlama hataları ve eylem hataları.
• Generalization bias in large language model summarization — büyük dil modelleri tarafından oluşturulan özetlerde aşırı genelleme riski.
• LLM uygulamaları için OWASP Top 10 — hassas bilgiler, aşırı bağımlılık, prompt ve güvenlik riskleri.