Daily Scrum ve AI: standup neden durum botu olmamalı

Bu, AI'nın çapraz fonksiyonel geliştirme ekibinin klasik toplantılarını nasıl değiştirdiğine dair serinin üçüncü makalesi. İlk makalede Backlog Refinement konusunu inceledim ve AI'nın materyal hazırlığını hızlandırdığını ama anlamın ekip tarafından kontrolünün yerini almadığını gösterdim. İkinci makalede Sprint Planningkonusuydu: AI bir plan taslağı oluşturabilir ama ekip taahhüdünü üstlenemez. Şimdi Daily Scrum'a geçmek ve buradaki en tehlikeli hatanın neden canlı senkronizasyonu otomatik bir durum botuna dönüştürmek olduğunu görmek mantıklı.

Daily Scrum otomasyon için ideal bir aday gibi görünüyor. Commit'ler Git'te var, görevler Jira'da var, pull request'ler GitHub veya GitLab'da var, olaylar izlemede var, yazışmalar Slack veya Teams'de var. AI hızlıca kısa bir özet çıkarabilir: kim dün ne yaptı, görevlerde ne değişti, engeller nerede takılıyor, hangi PR'lar uzun süredir review'suz, hangi ticket'lar ilerlemedi, mevcut iş hacminin yanında hangi bug'lar ortaya çıktı.

İlk bakışta bu neredeyse bariz bir kazanç gibi görünüyor. Daha az tekrarlayan durum. Daha az senkron toplantı. Daha az manuel yeniden anlatım. Özellikle farklı saat dilimlerinde çalışan ve her gün ortak bir slotu araçlarda zaten görünen şeyleri dile getirmeye harcamak istemeyen dağıtık ekiplerde.

Ama burada önemli bir tuzak var.

Daily Scrum raporlama için var değildir. Görevi, Geliştiricilerin Sprint Goal'e doğru ilerlemeyi kontrol etmesine, Sprint Backlog'u uyarlamasına ve yakın işi koordine etmesine yardımcı olmaktır. AI, Daily Scrum'ı dünkü aktivite hakkında otomatik bir rapora dönüştürürse, ekip daha düzgün bir durum elde edebilir ama en önemlisini kaybedebilir: sorunların canlı keşfi, shared awareness ve sonraki adımın sorumluluğu.

“AI durum gürültüsünün bir kısmını kaldırabilir, ama Daily Scrum durumla değil, planın uyarlanmasıyla değerlidir.”

Daily Scrum neden gerekli

İçinde Scrum Guide 2020 Daily Scrum oldukça katı bir şekilde tanımlanmıştır: Sprint Goal'a doğru ilerlemeyi kontrol etmek ve gerekirse yakın çalışma planını değiştirerek Sprint Backlog'u uyarlamak amacıyla Geliştiriciler için 15 dakikalık bir etkinliktir. Bu, Ürün Sahibine bir rapor değildir. Scrum Master'ın sabah kontrolü değildir. Görevlerin sırayla sayılması değildir. Ve günlük bir meşguliyet tutanağı değildir.

Ek bir referans olarak şu da faydalıdır: Scrum Guide Expanded v2026.1, ancak yeni bir kanonik Scrum Guide sürümü olarak değil, tam olarak bir tamamlayıcı (companion) kaynak olarak. Bu makale için pratik bir çerçeve olarak önemlidir: Daily Scrum orada uygulanabilir planın ortaklaşa güncellenmesi olarak tanımlanır ve akış (flow) mantığı çok net bir şekilde ifade edilir — "meşgul olmayan" insanlara değil, tıkanmış işe bakmak. AI destekli Daily'de bu kritiktir: AI, insanları günlük rapor satırlarına dönüştürmek yerine riskleri, engelleri (impediments) ve Sprint Backlog'da tıkanmış öğeleri vurgulamalıdır.

Daily Scrum'ın anlamı, ekibin her gün kendine pratik bir soru sorduğu yerde ortaya çıkar: son seferden bu yana ne öğrendik ve bu, önümüzdeki gün için planımızı nasıl değiştiriyor? Cevap "hiçbir şeyi değiştirmiyor" ise toplantı çok kısa olabilir. Cevap "sprint hedefiyle ilgili riskimiz var" ise Daily Scrum hızlı koordinasyonun yeri olur: toplantıdan sonra kim kiminle senkronize olacak, hangi engel yukarı taşınacak (escalate), iş kapsamından ne çıkarılmalı, hangi bağımlılık kontrol edilmeli, hangi göreve başlamamak daha iyi.

Bu nedenle Daily Scrum'ın amacını beş işlev üzerinden tanımlardım:

• ekibin Sprint Goal etrafında senkronizasyonu;
• sorunların ve engellerin hızlıca tespit edilmesi;
• yakın çalışmanın koordinasyonu;
• sprintin durumu hakkında ortak farkındalığın (shared awareness) sürdürülmesi;
• sadece bilgi alışverişi değil, planın uyarlanması.

Bu, AI hakkında konuşmak için önemli bir çerçevedir. Eğer araç, ekibin bu işlevleri daha iyi yerine getirmesine yardımcı oluyorsa faydalıdır. Eğer sadece durum raporunu daha güzel gösteriyorsa, kullanışlı olabilir ama teslimatı (delivery) mutlaka iyileştirmez.

Genellikle neler yanlış gider

Daily Scrum'ın sorunu nadiren insanların "üç soruyu" bilmemesidir. Sorun, etkinliğin zamanla alışılmış bir yönetim kalıbına dönüşmesidir: herkes sırayla ne yaptığını, ne yapacağını ve engel olup olmadığını rapor eder. Bu bazen asgari bir disiplin olarak faydalıdır, ancak çoğu zaman bu format fark edilmeden ekip koordinasyonunun yerine bireysel raporlamayı koyar. Scrum.org bu anti-kalıbı doğrudan şu materyalde ele alıyor: Daily Scrum is not a status meeting: Geliştiriciler başka birine rapor verdiklerinde, etkinlik öz-yönetim (self-management) ve plan uyarlama mekanizması olmaktan çıkar.

O zaman toplantı kendi amacına karşı çalışmaya başlar. Geliştiriciler birbirleriyle değil, Scrum Master'a veya yöneticiye doğru konuşurlar. Engeller çok geç veya çok yumuşak bir şekilde dile getirilir. Bağımlılıklar tartışılmaz çünkü "bu artık bir detay". İnsanlar aktiviteleri listeler ama Sprint Goal'a yaklaşıp yaklaşmadıklarını söylemezler. Ekip, planın dağıldığını ancak sprintin sonunda, kalite kaybı olmadan bir şeyleri uyarlamanın zaten zor olduğu zaman öğrenir.

AI destekli bağlamda bu sorun daha da güçlenebilir. Eğer model her gün Jira, Git ve Slack üzerinden kısa bir özet üretiyorsa, ekip hızla "durum zaten toplandı" düşüncesine alışır. O zaman Daily Scrum daha da biçimsel hale gelir: insanlar AI özetine bakar, onaylar, bazen birkaç cümle ekler ve dağılırlar.

Etkili görünüyor. Ama soru, durumun toplanıp toplanmadığı değil. Soru, gerçeklik değiştiyse ekibin planını değiştirip değiştirmediği.

AI gerçekten nerede yardımcı olur

AI'ın Daily Scrum'da oldukça pratik bir fayda alanı vardır. Rutin durum iletişimini azaltabilir ve insanların günlük akışta kolayca gözden kaçırdığı sinyalleri yüzeye çıkarabilir. Bu, özellikle çok sayıda kaynağa sahip ekiplerde değerlidir: issue tracker, pull request'ler, CI/CD, olay yönetimi, ürün analitiği, destek ticket'ları, takvim, dokümantasyon, yazışmalar.

Ama burada fazla söz vermemek önemlidir. En güncel DORA State of AI-assisted Software Development 2025 AI'ı daha iyi delivery'nin bağımsız bir garantisi olarak değil, mevcut organizasyonel pratiklerin bir güçlendiricisi olarak tanımlıyor. Daily Scrum için bu basit bir anlama gelir: ekip zaten Sprint Goal'u, riskleri ve planın uyarlanmasını tartışmayı biliyorsa, AI konuşmaya girişi zenginleştirebilir. Daily uzun zamandır bir durum ritüeli haline geldiyse, AI sadece bu durum ritüelini daha hızlı ve daha güzel hale getirir.

İyi bir AI yardımcısı Daily Scrum öncesinde "kim neyle meşguldü" değil, koordinasyon için faydalı bağlamı toplayabilir:

• hangi görevler beklenenden uzun süre ilerlemedi;
• hangi pull request'ler review gerektiriyor veya diğer değişiklikleri bloke ediyor;
• hangi testler veya build'ler kararsız hale geldi;
• sohbetlerde bahsedilen ama Jira'ya girmeyen hangi engeller vardı;
• Sprint Backlog'daki hangi öğeler artık Sprint Goal'u doğrudan desteklemiyor;
• nerede yeni bağımlılıklar, riskler veya çatışan değişiklikler ortaya çıktı;
• dün hangi kararlar asenkron olarak alındı ve tüm ekip tarafından görülmeli;
• Daily sonrası kısa bir takip gerektiren, herkesin önünde tartışılmaması gereken ne var.

Bu modda AI, Daily Scrum'ın yerini almaz. Ona hazırlanmanın maliyetini düşürür. Ekip boş bir hafızayla veya bireysel anlatımlarla değil, zaten toplanmış bir sinyal tablosuyla gelir. Bu, gerçekleri yeniden oluşturmaya daha az, "şimdi ne yapıyoruz?" sorusuna daha fazla zaman harcamayı sağlar.

Bu, serinin önceki makalelerinin mantığını sürdürüyor. Refinement'ta AI, tartışmaya malzeme toplamaya yardımcı oluyordu. Planning'de — plan seçenekleri. Daily Scrum'da ise sprintin gidişatına dair sinyalleri toplayabilir. Ancak her üç durumda da insani kısım ortadan kalkmaz: ekip neyin önemli olduğunu, neyin değiştiğini ve hangi kararların alınması gerektiğini doğrulamalıdır.

AI neden stand-up'ı bir durum botuna dönüştürmemeli

AI destekli Daily Scrum'ın en tehlikeli versiyonu çok teknolojik görünür: her sabah bot, her katılımcı için kısa bir özet, dünkü commit'lerin listesi, ticket durumları, açık PR'lar, olası engeller ve iş hacminin tamamlanmasına dair bir tahmin yayınlar. Bazen bot ayrıca herkesten kendi durumunu onaylamasını veya düzeltmesini ister.

Yönetsel kontrol açısından bu kullanışlıdır. Scrum açısından bu bir bozulma olabilir.

Birincisi, böyle bir format Daily Scrum'ı kolayca bireysel raporlamaya geri döndürür. İnsanlar ekibin Sprint Goal'a nasıl ilerlediğini değil, AI'ın kişisel aktivitelerini doğru tanımlayıp tanımlamadığını düşünmeye başlar. Dikkat, koordinasyondan itibar savunmasına kayar: "bot benim review'umu hesaba katmadı", "commit'im yoktu ama bir olayı inceliyordum", "Jira gerçek işi yansıtmıyor".

İkincisi, AI özeti yanlış bir ortak farkındalık hissi yaratabilir. Özet yayınlandıysa herkesin her şeyi bildiği görünür. Ama ortak farkındalık, kanalda bir metnin bulunması değildir. Neyin önemli olduğu, riskin nerede olduğu, kimin kiminle senkronize olması gerektiği ve planın nasıl değiştiğine dair ortak anlayıştır.

Üçüncüsü, otomatik durum zayıf sinyalleri gizleyebilir. Gerçek sorunlar genellikle Jira'nın biçimsel alanlarında değil, tonlamada, şüphede, belirsiz bir ifadede, kısa bir "sanırım yanlış yöne gidiyoruz" cümlesinde, görevler arasındaki gerginlikte, genellikle riskleri hızla dile getiren birinin sessizliğinde ortaya çıkar. AI bu tür sinyallerin bir kısmını metinde bulmaya yardımcı olabilir, ancak sorunları tespit etmenin tek mekanizması haline gelmemelidir.

Dördüncü olarak, ekip sahipliği/sorumluluğu araca devretmeye başlayabilir. Bot her şeyin yolunda olduğunu söylediyse, her şey yolundadır. Bot bir engelleyici işaretlemediyse, engelleyici yoktur. Bot iş hacminin tamamlanacağını öngörüyorsa, hoş olmayan ödünleşimleri tartışmaya gerek yoktur. Bu, Daily Scrum'ın otomasyonu değil, sorumluluğun olamayacağı bir yere taşınmasıdır.

“AI tarafından üretilen durum bilgisi yararlı bir girdi olabilir. Ekip muhakemesinin yerini almamalıdır.”

Vaka ile devam edelim: B2B LMS ve e-posta hatırlatmaları

İlk iki makaledeki aynı vakayı ele alalım: B2B LMS platformu, zorunlu kurslar, zorunlu kursu son tarihe kadar tamamlamayan çalışanlara e-posta hatırlatmaları. Planning'de ekip dar bir Sprint Goal seçti: sistem, zorunlu kursu tamamlamamış aktif çalışanlara son tarihten önce tek bir doğru hatırlatma gönderir ve doğrulanabilir gönderim geçmişini saklar.

Böyle bir sprintte AI olmadan Daily Scrum hızla bir dizi bireysel duruma dönüşebilir. Backend geliştiricisi zamanlayıcıyı yaptığını söyler. Diğer backend geliştiricisi tekilleştirme / yinelenenleri giderme ile ilgilendiğini söyler. QA saat dilimine göre senaryolar hazırladığını söyler. Frontend geçmiş günlüğü API'sini beklediğini söyler. Ürün Sahibi dinler. Scrum Master zamanı tutar. Biçimsel olarak her şey iyidir.

Ancak ekip en önemli şeyi kaçırabilir: scheduler neredeyse hazır, ama tekilleştirme geçmiş günlüğünde hangi anahtarın olacağına bağlı; QA, saat diliminin nerede saklandığına karar verilene kadar test verisi hazırlayamaz; frontend API'yi bekliyor, ama Sprint Goal için tam UI belki de hiç gerekli değil; Ürün Sahibi hâlâ nasıl yorumlanacağını onaylamadı: expired, oysa ekip bunu iş hacmi dışı sayıyor.

AI burada yardımcı olabilir. Daily'den önce sinyalleri toplar: scheduler PR'ı açık ama review yok; dünde sohbette yinelenme riski tartışıldı; geçmiş günlüğü ticket'ı güncellenmedi; QA saat dilimi hakkında yorum bıraktı; backlog item'ında müşteri destek ekibinden yeni bir netleştirme çıktı. Bu iyi bir girdidir.

Ancak değer yalnızca toplantıda, ekip bir sonraki adımı attığında ortaya çıkar: Daily'den hemen sonra kimin tekilleştirme anahtarını kontrol etmeye oturacağına, kimin saat dilimi politikasını onaylayacağına, Sprint Goal kapsamında geçmiş günlüğü için tam olarak neyin yeterli sayıldığına ve ekibin mevcut kapasitesini dağıtmamak için bugün UI üzerindeki işin durdurulup durdurulmayacağına karar verir. AI sinyalleri verdi. Ekip planı uyarladı.

Anti-pattern'ler

Aşağıda, AI'ın Daily Scrum'a entegrasyonunda özellikle izleyeceğim birkaç anti-pattern bulunuyor.

1. Bot, ekip bağlamı yerine kişisel raporlar topluyor

AI özeti insanlar etrafında değil de Sprint Goal etrafında yapılandırılmışsa, ekip hızla durum formatına kayar. Sinyalleri hedef, riskler, bağımlılıklar ve koordinasyon gerektiren kararlar etrafında gruplamak daha faydalıdır.

2. Ekip planı uyarlamak yerine özeti onaylıyor

Daily Scrum “evet, bot her şeyi doğru yazmış”a dönüştüğünde, etkinlik anlamını yitirir. İyi soru “durum doğru mu?” değil, “bunlardan hangisi bugünkü planımızı değiştiriyor?”dur.

3. AI sprint tamamlanmasını sanki nesnel gerçekmiş gibi öngörüyor

Tahmin yararlı bir sinyal olabilir, ancak riskler hakkındaki konuşmanın yerini almamalıdır. Özellikle model, karmaşıklık, kalite, bağımlılık ve Definition of Done anlayışı olmadan velocity, kapatılan ticket sayısı veya depo etkinliğine dayanıyorsa.

4. Engelleyiciler yalnızca sistemlerde aranıyor

Her engelleyici dijital iz bırakmaz. Bazen sorun belirsiz bir kararda, rahatsız edici bir soruyu gündeme getirme korkusunda, öncelik çatışmasında, ekip yorgunluğunda veya ekip dışındaki bir kişiye gizli bağımlılıkta olabilir. AI yardımcı olabilir, ancak dikkat alanını araçlardan kolayca çıkarılabilen şeylerle sınırlamamalıdır.

5. Daily bir etkinlik kontrol kanalına dönüşüyor

AI insanların “faydasını” commit'ler, yorumlar, kapatılan görevler veya yanıt süresiyle ölçmeye başlarsa, ekip hızla görünür etkinliğe göre optimize olur. Bu güveni zedeler ve insanların Daily Scrum'a getirmeye istekli olduğu bilginin kalitesini düşürür.

6. Asenkron özet, koordinasyonun gerektiği yerde konuşmanın yerini alıyor

Asenkronluk olguları aktarmak için faydalıdır. Ancak Sprint Goal'e dair risk, bağımlılık çatışması veya planı hızla değiştirme ihtiyacı varsa, canlı konuşma genellikle uzun bir yorum zincirinden daha ucuzdur.

Roller nasıl değişecek

AI, Scrum Team içindeki rolleri ortadan kaldırmaz, ancak günlük koordinasyondaki vurguyu değiştirir. Olguları elle aktarmanın değeri azalır. Sinyalleri doğrulama, karar alma ve ekip sorumluluğunu koruma değeri artar.

Rol	Kötü AI senaryosunda risk	Olgun AI kullanımı
Geliştiriciler	AI özetini pasifçe onaylar ve Sprint Backlog'u kendileri uyarlama alışkanlığını kaybeder.	AI sinyallerini girdi olarak kullanır, ancak planda neyin değişeceğine, kimin kiminle senkronize olacağına ve hangi ödünleşimlerin gerektiğine kendileri karar verir.
Ürün Sahibi	Kullanışlı bir günlük rapor alır ve Daily Scrum'a kendisi için bir şeffaflık kanalı olarak bakmaya başlar.	Ekipte Sprint Goal'e dair risk oluşursa değerin, iş hacminin ve iş hacmi dışının hızla netleştirilmesine yardımcı olur.
Scrum ustası	Kolaylaştırıcılığı bota devreder ve yalnızca insanların durumları güncellemesini takip eder.	Daily Scrum'ı raporlamaya dönüşmekten korur, ekibin riskleri, engelleri ve plan uyarlamasını tartışmasına yardımcı olur.
Kalite Mühendisi / QA Mühendisi	Uzun bir AI tarafından üretilen kontrol listesi alır ve kapsam görüntüsü yaratır.	Ön riskleri bulmak için AI kullanır, ancak test edilebilirliği, gözlemlenebilirliği, verileri ve gerçek hata modlarını elle doğrular.
UX/UI tasarımcısı	Daily'den düşer, çünkü AI özeti kod, PR ve geliştirme görevlerine odaklanır.	UX bağımlılıklarını, iş kapsamı kararlarını ve Sprint Goal ile kullanıcı değerini etkileyen soruları vurgular.
Mühendislik Lideri / Teknik Lider	AI özetini aktivite yönetim paneli gibi okumaya başlar.	Özeti teknik riskleri, inceleme darboğazlarını, entegrasyon çatışmalarını ve gizli bağımlılıkları erken tespit etmek için kullanır.

AI destekli Daily Scrum için pratik bir filtre

“AI standup botu” uygulamakla başlamazdım. Daha dar bir soruyla başlardım: hangi sinyaller ekibin sprint planını daha hızlı uyarlamasına yardımcı olur? Bundan sonra AI, etkinliğin yerine geçen bir şey olarak değil, bir hazırlık katmanı olarak kullanılabilir.

Daily öncesi AI özeti şu soruları yanıtlamaya yardımcı oluyorsa faydalıdır:

• Sprint Goal'e ulaşma riski değişti mi?
• Ne engellendi veya yakında engellenecek?
• Bugün hangi bağımlılıklar canlı koordinasyon gerektiriyor?
• Asenkron olarak hangi kararlar alındı ve tüm ekip tarafından görünür hale gelmeli?
• Jira durumu ile işin gerçek durumu arasında nerede fark var?
• Daily sonrası hangi takip görüşmeleri gerekli ve bunlara kim katılıyor?
• Sprint Goal risk altındaysa ekip ne yapmayı bırakmalı?

Ve tam tersi: AI özeti esas olarak “kim neyle meşguldü” sorusunu yanıtlıyorsa, bu Daily Scrum değildir. Bu raporlamadır. Organizasyonda gerekli olabilir, ancak bunu ekip incelemesi ve uyarlamasıyla karıştırmamak gerekir.

Veri yönetimi ve hijyeni

Daily Scrum verilere özellikle duyarlıdır, çünkü AI özeti kolayca kişisel mesajlardan, takvimlerden, inceleme yorumlarından, üretim olaylarından, destek taleplerinden ve iç tartışmalardan bilgi toplamaya başlar. Erişim ne kadar genişse özet o kadar ikna edici olur. Ancak aşırı gözetim, bağlam sızıntısı ve modelin kendinden emin ama eksik çıkarımına aşırı bağımlılık riski de o kadar artar. Tam da bu risk sınıfları şurada iyi tanımlanmıştır: NIST Generative AI Profile ve OWASP Top 10 for LLM Applications 2025.

Ekip, AI için hangi kaynakların izinli olduğunu, hangi alanların hariç tutulduğunu, özeti kimin gördüğünü, ne kadar süre saklandığını ve bireysel performans değerlendirmesi için kullanılıp kullanılamayacağını önceden kararlaştırmalıdır. Son madde kritiktir. İnsanlar Daily AI özetinin verimlilik kontrolü için bir proxy olarak kullanıldığını hissederse, davranışlarını metriklere göre optimize etmeye başlar ve rahatsız edici sinyalleri getirmeyi bırakır. Bu artık “kullanışlı standup” meselesi değil, çalışan izleme meselesidir: şu düzenleyici referanslar ICO monitoring at work impact assessment ve EDPB Opinion 28/2024 makale için hukuki bir talimat olarak değil, gereklilik, orantılılık, veri minimizasyonu ve şeffaflık ihtiyacının hatırlatıcısı olarak faydalıdır.

Pratikte bu şu anlama gelir: modele gereksiz kişisel veri çekmemek, özel yazışmaları açık bir gerekçe olmadan analiz etmemek, aktivite sıralamaları oluşturmamak, teslimat sinyallerini performans yönetimiyle karıştırmamak ve olguları varsayımlardan ayırmak. AI ekibin işi görmesine yardımcı olmalı, insanları gözetleme mekanizmasına dönüşmemelidir.

Pratik sonuç

AI gerçekten Daily Scrum'ı daha faydalı hale getirebilir. Tekrarlayan durum bildirimlerinin bir kısmını kaldırabilir, olguları önceden toplayabilir, engelleri vurgulayabilir, inceleme darboğazlarını bulabilir, görevler ile gerçeklik arasındaki farkları fark edebilir, dünkü kararları hatırlatabilir ve koordinasyon için kısa bir konu listesi hazırlayabilir.

Ancak bu yalnızca ekip sınırı anlarsa işler: AI girdiyi hazırlar, Daily Scrum'ı yürütmez. Sinyalleri görmeye yardımcı olur ama onlarla ne yapılacağına karar vermez. Kısa bir özet önerebilir ama tek başına ortak farkındalık yaratmaz. Riski fark edebilir ama plan uyarlamasının sorumluluğunu üstlenmez.

Bu nedenle ana tezi şöyle formüle ederdim: AI, durum iletişiminin maliyetini azaltmalı ki ekipte koordinasyona daha fazla dikkat kalsın. Bunun tersi olur ve Daily Scrum AI tarafından üretilen durum raporlamasına dönüşürse, ekip etkinliğin var olma nedenini tam olarak kaybeder: canlı senkronizasyon, sorunların erken tespiti, ortak sorumluluk ve planı hızla değiştirme yeteneği.

Olgun bir ekip şunu sormaz: “standup'ı bir botla değiştirebilir miyiz?”. Farklı sorar: “AI durum gürültüsünün hangi kısmını kaldırabilir ki Daily Scrum'ımız Sprint Goal ve yakın plan hakkında daha dürüst bir konuşma olsun?”. Bu çok daha az gösterişli bir ifadedir. Ama gerçek teslimat pratiğine daha yakındır.

Kaynaklar ve referanslar

• Scrum Guide 2020 — Daily Scrum, Sprint Goal, Sprint Backlog, Geliştiriciler, inceleme ve uyarlama.
• Scrum Guide Expanded v2026.1 — Scrum Guide 2020 tabanlı companion kaynak: Daily Scrum için pratik çerçeve, uygulanabilir plan, riskler / engeller ve “idle work, not idle people” akış yaklaşımı.
• Scrum.org: What is a Daily Scrum? — Daily Scrum'un amacı ve Sprint Goal ile bağlantısına dair pratik açıklama.
• Scrum.org: Daily Scrum is not a status meeting — Daily Scrum neden bireysel raporlamaya dönüşmemelidir.
• NIST AI Risk Management Framework 1.0 — yönetişim / düzenleme, hesap verebilirlik / sorumluluk, insan-AI etkileşiminin yapılandırılması.
• NIST Generative AI Profile — aşırı bağımlılık, konfabülasyon / kendinden emin uydurma, gizlilik ve insan kontrolü.
• OWASP Top 10 for LLM Applications 2025 — hassas bilgi ifşası, dezenformasyon, aşırı ajans ve LLM uygulamalarının operasyonel riskleri.
• DORA State of AI-assisted Software Development 2025 — AI, delivery iyileştirmesinin bağımsız garantisi değil, organizasyonel pratiklerin güçlendiricisi olarak.
• EDPB Opinion 28/2024 ve ICO monitoring at work impact assessment — kişisel veriler, minimizasyon, şeffaflık ve çalışan izleme konusunda yönlendirici ilkeler.