AI ve Scrum Events: geliştirme ekibi toplantılarında gerçekte ne değişiyor
Serinin özeti: AI, Scrum Events'i nasıl değiştiriyor, ekibe nerede yardımcı oluyor, hangi riskleri artırıyor ve sorumluluk neden hâlâ insanlarda kalıyor.
Bu görsel yüklenemedi.Bu, AI'nın çapraz fonksiyonel geliştirme ekibinin klasik toplantılarını nasıl değiştirdiğine dair serinin son makalesi. Önceki bölümlerde ayrı ayrı inceledim Backlog Refinement, Sprint Planning, Daily Scrum, Sprint Review ve Sprint Retrospective. Bunları bir araya getirdiğimizde ortaya çıkan genel sonuç oldukça ayık: AI, Scrum events'e hazırlığı daha ucuz ve daha zengin hale getiriyor, ancak inceleme, adaptasyon, konuşma ve gerçek değişiklikler konusundaki sorumluluğu ekipten almıyor.
Bu seriye başladığımda iki uç senaryodan birine kaymak kolaydı. Birincisi: AI yakında neredeyse tüm ekip toplantılarının yerini alacak, çünkü model zaten özetleme yapabiliyor, görevler yazabiliyor, planlar üretebiliyor, durumları toplayabiliyor, demo hazırlayabiliyor ve action item'lar önerebiliyor. İkincisi: Scrum events doğası gerekiyor o kadar insani ki AI orada neredeyse gerekli değil.
Beş ayrı incelemeden sonra bana öyle geliyor ki her iki senaryo da fazla düz.
AI gerçekten ekip toplantılarını değiştiriyor. Ama reklam vaatlerinde genellikle söylendiği gibi değil. Scrum events'in çekirdeğini değil, etraflarındaki katmanı değiştiriyor: hazırlık, arama, özetleme, ilk yapılandırma, sinyalleri tespit etme, kararları kaydetme ve follow-up. Ve bu katman ucuzladıkça, anlam kaybı olmadan otomatikleştirilemeyecek şeyler daha belirgin hale geliyor: ekip yargısı, sorumluluk, değer tartışması, gerçeklik kontrolü, psikolojik güvenlik ve planı, backlog'u veya çalışma biçimini değiştirme yeteneği.
“AI hazırlığı daha ucuz hale getiriyor, ama insan sorumluluğunu daha belirgin hale getiriyor.”
Bu, serinin sorusuna verilen ana cevaptır. AI, klasik çapraz fonksiyonlu geliştirme ekibi toplantılarını ortadan kaldırmaz. Onların dikkat ekonomisini değiştirir. Rutin olgu toplama daha ucuz hale gelir. Özenli taslaklar üretmek daha ucuz hale gelir. Statü iletişimi daha ucuz hale gelir. Ancak Scrum etkinliklerinin gerçek değeri yine de ekibin olgulara baktığı, anlam üzerine tartıştığı, uzlaşma kabul ettiği ve sonraki eylemleri değiştirdiği yerde ortaya çıkar.
Önce toplantıların amacına geri dönmek faydalıdır
Şurada: Scrum Guide 2020 Scrum etkinlikleri bir ritüeller kümesi olarak değil, şeffaflık, inceleme ve uyarlama için yerleşik olanaklar olarak tanımlanır. Sprint Planning sprinti başlatır ve ekibin değer, iş hacmi ve yürütme biçimi konusunda anlaşmasına yardımcı olur. Daily Scrum, Geliştiricilerin Sprint Goal'e doğru ilerlemeyi kontrol etmesi ve Sprint Backlog'u uyarlaması için gereklidir. Sprint Review, sonucun incelenmesi ve Product Backlog'un daha sonra uyarlanması için gereklidir. Sprint Retrospective, ekibin çalışma kalitesini ve etkinliğini artırmak için gereklidir.
Backlog Refinement ayrı durur: Scrum Guide 2020'de resmi bir Scrum etkinliği değil, Product Backlog'un netleştirilmesine yönelik süregelen bir faaliyettir. Ancak gerçek hayatta çapraz fonksiyonlu bir ekibin refinement'ı sıklıkla önemli bir düzenli toplantı veya bir dizi çalışma oturumu olarak işler. Bu nedenle bu seride onu klasik etkinliklerin yanında ele aldım: tam da ekip ilk kez AI'ın en erken hızlandırmaya başladığı büyük hacimli manuel entelektüel hazırlıkla orada karşılaşır.
Bu çerçeve önemlidir, çünkü yanlış sorudan korur. Kötü soru şudur: “AI hangi toplantının yerini alabilir?”. Daha doğru soru: “Toplantının kendisi daha dürüst bir inceleme ve uyarlama haline gelsin diye AI manuel hazırlığın hangi kısmını alabilir?”.
Serinin son makalelerinde ek bir yönlendirici olarak şunu kullandım: Scrum Guide Expanded v2026.1. Bu, yeni bir kanonik Scrum Guide sürümü olarak değil, Scrum Guide 2020 temelinde bir companion kaynak olarak okunmalıdır. AI konusu için oradaki modelin supervised decision-making partner olarak formüle edilmesi faydalıdır: AI transparency, inspection ve adaptation'ı güçlendirebilir, ancak human accountability'nin yerini almaz ve empirical process control'ü ortadan kaldırmamalıdır. Sonuç makalesi için bu neredeyse ideal bir sınırdır.
Beş bölümün tamamında tekrarlanan şey
Şu makalede: Backlog Refinement ana sonuç şuydu: AI, ekibin anlaşmasının kendisini değil, ona yönelik malzemenin hazırlanmasını hızlandırır. Bağlamı, kullanıcı hikâyesi taslağını, kabul kriterlerini, riskleri, açık soruları ve ilk çözüm seçeneklerini toplamaya yardımcı olur. Ancak aynı zamanda yanlış bir netlik riski yaratır: görev, iyi biçimlendirildiği için anlaşılır görünür.
Şu makalede: Sprint Planning benzer bir örüntü başka bir düzeyde ortaya çıktı. AI, Sprint Goal seçeneklerini, iş hacmini, bağımlılıkları, ayrıştırmayı ve riskleri daha hızlı toplamaya yardımcı olur. Ancak yanlış bir gerçekçilik ortaya çıkar: plan tutarlı, eksiksiz ve uygulanabilir görünür, oysa ekip onu henüz kapasite, Definition of Done, test edilebilirlik ve gerçek kısıtlar açısından doğrulamamıştır.
Şurada: Daily Scrum AI artık gelecekteki işi hazırlamıyor, sprintin gidişatına dair sinyalleri topluyor. Blokerleri, review darboğazlarını, kararsız testleri, Jira durumu ile gerçeklik arasındaki tutarsızlıkları, bağımlılıkları ve asenkron alınan kararları işaretleyebilir. Ancak odak Sprint Goal'dan "kim neyle meşguldü"ye kayarsa, Daily Scrum AI tarafından üretilen durum raporlamasına dönüşür.
İçinde Sprint Review AI, sprint sonucu, metrikler, release notes, geri bildirim ve açık ürün soruları için hazırlık katmanı olarak faydalıdır. Ama tam burada demo tiyatrosu riski özellikle belirginleşir: model genel bakışı güzelleştirir, ekip cilalanmış bir hikâye gösterir, paydaşlar başını sallar ve Product Backlog değişmez.
İçinde Sprint Retrospective AI konuşmaya somut kanıt getirebilir: tekrarlayan engeller, review beklemesi, tamamlanmamış action item'lar, Definition of Done ile tutarsızlıklar, tekrarlayan örüntüler. Ama iyileştirme öneri listesinden doğmaz. Ancak ekip sorunu kabul ettiğinde, bir değişiklik seçtiğinde, bir sahip belirlediğinde ve bunu bir sonraki sprinte taşıdığında ortaya çıkar.
Bu çıkarımları yan yana koyunca ortak bir desen beliriyor: AI neredeyse her yerde toplantıya girişi zenginleştiriyor. Ve neredeyse her yerde zengin girişi çoktan alınmış bir kararla karıştırma cazibesi yaratıyor.
Scrum etkinliklerine göre değişim haritası
| Toplantı / pratik | AI neyi ucuzlatıyor | İnsanlarda ne kalıyor | Ana risk |
|---|---|---|---|
| Backlog Refinement | Bağlam toplama, görev tanımı taslağı, kabul kriterleri, sınır durumlar, açık sorular. | Anlamın, alan kurallarının, teknik kısıtların ve görevi tartışmaya hazır olmanın doğrulanması. | Yanlış netlik: görev iyi yazıldığı için hazır görünüyor. |
| Sprint Planning | Sprint Goal seçenekleri, kapsam, bağımlılıklar, riskler, ayrıştırma, test senaryoları. | Hedef, kapsam, gerçekçilik, Definition of Done ve sprint taahhüdü hakkında ekip kararı. | Yanlış gerçekçilik: plan akıcı biçimde toplandığı için uygulanabilir görünüyor. |
| Daily Scrum | Sprintin gidişatı, blokerler, PR'lar, testler, kararlar ve bağımlılıklar hakkında ön sinyaller. | Ortak farkındalık, Sprint Backlog'un uyarlanması ve yakın işte neyin değişeceğine dair karar. | Durum botu: toplantı Sprint Goal hakkında konuşma yerine insanlar hakkında rapora dönüşür. |
| Sprint Review | Release notes, sonuç tablosu, ürün metrikleri, geri bildirim ve açık sorular. | İnkrementin dürüst denetimi, paydaşlarla konuşma ve Product Backlog'un uyarlanması. | Demo tiyatrosu: güzelce gösterildi ama ürün kararları alınmadı. |
| Sprint Retrospective | Süreçle ilgili olgular, tekrarlayan örüntüler, eski action item'lar, konuşma için kanıt. | Psikolojik güvenlik, sorunun kabulü, iyileştirme seçimi ve takip. | Ekibin davranışını değiştirmek yerine AI önerileri listesi. |
Bu tablo AI'ın Scrum'ı "iyileştirdiğini" söylemiyor. Bu fazla güçlü bir iddia olurdu. Özellikle AI destekli Scrum etkinliklerine dair doğrudan bağımsız kanıt tabanı henüz az ve serinin bazı research brief'lerinde bu boşluğu özellikle belirttim. Daha dikkatli ifade farklı: AI olgun bir denetim ve uyarlama pratiğini güçlendirebilir, ama ekipte zaten yaşıyorsa eski bir anti-örüntüyü de aynı kolaylıkla güçlendirir.
Bu, şu temkinli çerçeveyle iyi örtüşüyor DORA State of AI-assisted Software Development 2025: AI, daha iyi delivery'nin bağımsız garantisi olarak değil, mevcut örgütsel sistemin güçlendiricisi olarak görülmeli. Ekip değer, risk, kalite ve süreci tartışabiliyorsa AI girdiyi zenginleştirir. Ekip denetimi durumla değiştirmeye alışkınsa AI durumu daha hızlı ve daha güzel yapar.
Uçtan uca vaka: B2B LMS ve email hatırlatmaları
Serideki tüm makalelerde tek bir örneği tuttum: büyük müşterilerin çalışanlara zorunlu kurslar atadığı ve ekibin zorunlu kursu son tarihe kadar tamamlamayanlara email hatırlatmaları eklediği bir B2B LMS platformu. Bu vaka, AI'ın tek bir toplantıyı değil tüm ekip dikkati zincirini değiştirdiğini iyi gösteriyor.
Refinement'ta AI müşteri bağlamını, benzer talepleri, atama durumlarını, bildirim mimarisini, saat dilimleri, tekilleştirme, dil ayarı ve geçmiş kaydıyla ilgili soruları toplamaya yardımcı olur. Ekip anlamlı bir backlog item'a daha hızlı ulaşır. Ama yine de neyin tamamlanmamış kurs sayılacağına, expiredile nasıl başa çıkılacağına, ilk sürümün sınırlarının nerede olduğuna ve hangi verilerin modele verilemeyeceğine karar vermelidir.
Planning'de AI birkaç Sprint Goal ve iş kapsamı seçeneği toplamaya yardımcı olur: minimal, genişletilmiş, iddialı, kapsam dışı. Ekip ödünleşimleri daha hızlı görür. Ama yine de sprinte gerçekte neyin sığdığına, neyin Sprint Goal'u desteklediğine, neyin ilk önce çıkarılabileceğine ve Definition of Done ile ilgili risklerin nerede saklı olduğuna dürüstçe yanıt vermelidir.
Daily Scrum'da AI sinyalleri kaldırır: scheduler PR'ı review olmadan açık, QA test verilerini bekliyor, sohbette duplikasyon riski tartışıldı, saat dilimiyle ilgili belirsizlik ortaya çıktı, destek yeni bir müşteri sorusu getirdi. Bu iyi bir girdidir. Ama Daily'den sonra kimin senkronize edilmesi gerektiğine, hangi riskin yükseltileceğine ve yakın planın nasıl uyarlanacağına ekip kendisi karar verir.
Sprint Review'da AI sonucu ve geri bildirimi toplar: kime hatırlatmalar gitti, open/click oranları neydi, destek ekibine hangi ticket'lar geldi, pilot müşteriler ne söyledi, bu Sprint Goal ile hangi backlog item'ları ilişkili. Ancak ürün değeri yalnızca Scrum Team ve paydaşlar bundan sonra ne yapılacağına karar verdiğinde ortaya çıkar: eligibility'yi netleştirmek, backlog'u değiştirmek, destek için tanılama eklemek veya önceliği yeniden gözden geçirmek expired.
Sprint Retrospective'te AI, ekibin test verilerini yine geç aldığını, review'ların benzer yerlerde takıldığını, Definition of Done'ın roller arasında örtük olarak ayrıştığını ve önceki sprint'teki action item'ın tamamlanmadığını görmeye yardımcı olur. Ancak iyileştirme yalnızca ekip bir sonraki sprint için tek ve somut bir deney seçtiğinde başlar: örneğin test verilerinin owner'ını önceden belirlemek, PR boyutunu küçültmek veya email gönderimi olan görevler için DoD'u netleştirmek.
Aynı vaka asıl noktayı gösteriyor: AI olgu ipliğini tüm sprint boyunca taşıyabilir. Ancak bu olguları faydalı kılan kararların yerini alamaz.
AI'ın hızlandırdığı beş anti-pattern
AI'da en rahatsız edici şey bazen hata yapması değildir. Hatalar yakalanabilir. En rahatsız edici olan, kötü bir süreci çok ikna edici hale getirebilmesidir.
Yanlış netlik. Refinement'ta ekip düzgün bir user story, ayrıntılı acceptance criteria ve edge case listesi görür. Görev anlaşılmış gibi görünür. Ancak olgular kaynaklara izlenemiyorsa ve açık sorular akıcı metnin altına saklanmışsa, ekip yalnızca hazır olma illüzyonunu daha hızlı yaratmıştır.
Yanlış gerçekçilik. Planning'de model güzel bir Sprint Plan toplar: hedef, scope, bağımlılıklar, risks, steps, estimates. Ancak Geliştiriciler capacity'yi, DoD'u, tamamlanmamış işi ve gerçek kısıtları kontrol etmediyse, bu bir plan değildir. Bu, iyi biçimlendirilmiş bir umuttur.
Durum botu. Daily Scrum'da AI her gün kimin ne yaptığını, Jira'da neyin değiştiğini ve hangi PR'ların açık olduğunu yazar. Bu kullanışlıdır. Ancak ekip Sprint Goal ve planın yakın adaptasyonu hakkında konuşmayı bıraktıysa, Daily Scrum raporlamaya dönüşmüştür.
Demo tiyatrosu. Sprint Review'da AI slaytları, release notes ve geri bildirim özetini hazırlar. Her şey profesyonel görünür. Ancak paydaşlar tartışmıyorsa, Product Backlog değişmiyorsa ve rahatsız edici sinyaller ortalamaya vuruluyorsa, ekip bir sunum yapmıştır, Review değil.
Değişimsiz retrospektif. Retrospective'te AI root cause'lar ve action item'lar önerir. Ancak insanlar dürüstçe konuşmaya hazır değilse, owner, etki kontrolü ve bir sonraki Sprint Backlog'da yer yoksa, bu improvement değildir. Bu, iyileştirme olmadan iyileştirme tutanağıdır.
Beş anti-pattern'in hepsi aynı doğaya sahiptir: AI formun maliyetini düşürür, ama form içerik gibi davranmaya başlar. Bu yüzden serideki makalelerde overreliance, confabulation, misinformation, information integrity, privacy ve human oversight kaynakları bu kadar sık tekrarlandı: NIST AI Risk Management Framework 1.0, NIST Generative AI Profile ve OWASP Top 10 for LLM Applications 2025 bu risk sınıflarını AI sistemleri düzeyinde iyi tanımlar. Scrum ekibinde bunlar çok somut biçimde ortaya çıkar: güzel bir taslağa aşırı güven olarak.
Ekipte neyin güçlenmesi gerekir
AI hazırlığı hızlandırıyorsa, ekip yanlışlıkla daha az disipline ihtiyacı olduğuna karar verebilir. Pratikte tam tersi. Taslaklar ne kadar hızlı oluşturulursa, doğrulama disiplini o kadar önemli olur.
Daha az değil, daha önemli hale gelen beş ekip becerisini öne çıkarırdım.
Birincisi: olguları varsayımlardan ayırmak. Herhangi bir AI girdisinde neyin kaynaklardan geldiği, neyin modelin yorumu olduğu ve neyin çalışma hipotezi olduğu görünmelidir. Bu özellikle refinement, planning ve Review'da önemlidir; çünkü hata kolayca bir backlog item'ına veya ürün kararına dönüşebilir.
İkincisi: yalnızca bütünlüğü değil, inandırıcı akıcılığı da kontrol etmek. İyi bir AI taslağı reviewer'ı “buraya daha ne eklenebilir?” diye değil, “burada ne yanlış olabilir?”, “özetten hangi bağımlılık kaybolmuş olabilir?”, “model hangi rahatsız edici sinyali ortalamaya vurdu?” diye sorar.
Üçüncüsü: AI sinyallerini insan değerlendirmesi olarak kullanmamak. Daily Scrum ve Retrospective bu sınıra özellikle duyarlıdır. Model Jira, Git, PR comments ve sohbetleri okursa, iş analizinden gizli monitoring'e geçmek çok kolaydır. Bu güveni yıkar ve konuşmayı temkinli hale getirir. Pratikte bu şu anlama gelir: work and system, not people analiz edilir.
Dördüncüsü: doğrulama sahiplerini atamak. İş anlamını Ürün Sahibi doğrular. Gereksinim tutarlılığını analist. Mimari kısıtları geliştiriciler. Testability ve failure modes'u QA. UX sınırlarını tasarımcı. Toplantı ve ekip mutabakatı kalitesini Scrum Master. AI ortak bir taslak hazırlayabilir, ancak doğrulamanın sahibi olamaz.
Beşincisi: kararları işin değişimine kadar götürmek. Sprint Review sonucunda Product Backlog değişmediyse ve Sprint Retrospective sonucunda doğrulanabilir bir next-sprint experiment ortaya çıkmadıysa, AI belgeye yardımcı olmuş olabilir, ama Scrum'a yardımcı olduğu kesin değildir.
Serbest kalan zaman nereye gider
Dizinin en önemli sorularından biri aslında teknik değil. AI ekibe hazırlıkta zaman kazandırıyorsa, bu zaman nereye gidiyor?
Kötü cevap: hemen daha fazla görevle doldurmak. O zaman AI sadece akış yoğunluğunu artırır ve aşırı yüklenmeyi maskeler. Ekip görevleri daha hızlı hazırlar, planları daha hızlı toplar, durumları daha hızlı yazar ve protokolleri daha hızlı yayınlar, ancak kararların kalitesine karşı daha dikkatli hale gelmez.
Daha olgun cevap: serbest kalan zamanın bir kısmını, önceden sürekli aciliyete yenilen şeylere yatırmak. Tartışmalı müşteri bağlamını kontrol etmek. Definition of Done'ı netleştirmek. Test verilerini tamamlamak. Tekrarlayan review sorununu ele almak. Dokümantasyonu iyileştirmek. Teknik borcu azaltmak. Tamamen dürüst olmak gerekirse, zor bir planning öncesi uyumak.
AI, ekip sadece daha fazla iş yaptığında değil, bariz olanı tekrar anlatmaya daha az dikkat harcamaya ve önceden gürültü yüzünden ertelenen kararlara daha fazla dikkat harcamaya başladığında faydalıdır.
AI'ı Scrum event'lerine yerleştirmenin pratik yolu
Ekip bana nereden başlamalı diye sorsaydı, büyük bir "AI-transformation of Scrum" ile başlamazdım. Event'lere hazırlık için küçük bir haritayla başlardım.
AI'ı her toplantıya yerleştirmeden önce yedi soruya cevap vermek gerekir:
- bu toplantıda inceleme ve uyarlamaya gerçekten hangi girdi yardımcı oluyor;
- hangi kaynaklar kullanılabilir, hangileri kullanılamaz;
- gerçekler, hipotezler ve model yorumları nasıl ayrılır;
- işi, mimariyi, testi, UX'i, veriyi ve riskleri kim kontrol ediyor;
- bu toplantının hangi anti-pattern'ini AI güçlendirebilir;
- AI önerisinin üzerinde neyin human override sayılacağı;
- ekip, etkinliğin sadece daha kısa değil, daha faydalı hale geldiğini nasıl anlayacak.
Son soru özellikle önemli. Toplantı süresinin kısalması tek başına iyileşmeyi kanıtlamaz. Ekip planı uyarlamayı bıraktıysa Daily Scrum daha kısa ve daha kötü hale gelebilir. Geri bildirim kaybolduysa Sprint Review daha güzel ve daha zayıf hale gelebilir. Action item'ları kimse uygulamıyorsa Retrospective daha düzenli ve daha faydasız hale gelebilir.
Bu yüzden ben "kaç dakika tasarruf ettik"e değil, daha canlı göstergelere bakardım: ekip riskleri daha erken görüyor, gerçekler hakkında daha az tartışıyor, bilinmeyenleri daha iyi ayırıyor, Review sonrası Product Backlog'u daha sık değiştiriyor, sprint içinde Sprint Backlog'u daha dürüst uyarlıyor, Retrospective sonrası daha az ama daha somut improvement experiment seçiyor.
Yani gerçekte ne değişiyor
AI, klasik Scrum toplantılarını hazırlık ve analiz katmanının güçlendiricisi olarak değiştirir. Refinement için malzemeyi, planning için plan varyantlarını, Daily Scrum için sinyalleri, Sprint Review için sonucu ve geri bildirimi, Retrospective için gerçekleri ve pattern'leri daha hızlı toplar.
Ama ana ilkeyi değiştirmez: Scrum event'leri belge, durum, demo ve protokol üretmek için var değildir. İnceleme ve uyarlama için vardır. AI ekibin gerçekliği daha iyi görmesine ve bilinçli karara daha hızlı geçmesine yardımcı oluyorsa faydalıdır. AI eski ritüeli daha pürüzsüz hale getiriyorsa ekip Scrum iyileşmesi değil, eski sorunun hızlandırılmış bir versiyonunu elde eder.
Bu yüzden nihai sonucum şu: AI'ı Scrum event'lerine toplantıların yerine değil, insan incelemesinin altında bir hazırlık katmanı olarak yerleştirmek gerekir. AI gerçekleri toplasın, varyantlar önersin, riskleri vurgulasın, kararları hatırlatsın ve follow-up'ı kaydetmeye yardımcı olsun. Ama ekip, Scrum'ın var olma nedenini kendinde tutmalı: şeffaflık, kontrol, uyarlama, sorumluluk ve sonraki işi dürüstçe değiştirme yeteneği.
Olgun ekip şunu sormaz: "artık hangi toplantıları kaldırabiliriz?". Farklı sorar: "AI gürültünün hangi kısmını alabilir ki biz anlam, değer, kalite ve davranış değişikliğine daha fazla dikkat ayırabilelim?". Bu daha az gösterişli bir soru. Ama çapraz fonksiyonlu geliştirme ekibinin gerçek işine çok daha yakın.
Kaynaklar ve referanslar
- Backlog Refinement ve AI: gerçekte ne değişiyor — dizinin ilk makalesi: AI tartışmaya hazırlık malzemesini hızlandırır, ancak yanlış bir netlik riski yaratır.
- AI-assisted Sprint Planning: sorumluluğu kaybetmeden hazırlığı nasıl hızlandırmalı — dizinin ikinci makalesi: AI plan varyantlarını hızlandırır, ancak ekibin kontrolü olmadan planı gerçekçi yapmaz.
- Daily Scrum ve AI: standup neden status-bot'a dönüşmemeli — dizinin üçüncü makalesi: AI sinyaller için faydalıdır, ancak günlük raporlama üreticisi olarak tehlikelidir.
- Sprint Review ve AI: demo neden değer konuşmasının yerini almaz — dizinin dördüncü makalesi: AI sonucu ve feedback'i toplamaya yardımcı olur, ancak Product Backlog uyarlamasının yerini almaz.
- Sprint Retrospective ve AI: iyileştirmeler neden modele devredilemez — dizinin beşinci makalesi: AI evidence getirir, ancak psychological safety ve follow-through yaratmaz.
- Scrum Guide 2020 — Scrum event'leri, transparency, inspection, adaptation, Sprint Goal, Product Goal, Sprint Backlog, Product Backlog ve accountabilities için kanonik çerçeve.
- Scrum Guide Expanded v2026.1 — Scrum Guide 2020 temelinde companion kaynak; AI'ı supervised decision-making partner olarak pratik çerçevede ele almak için faydalıdır, ancak Scrum Guide'ın yerini almaz.
- NIST AI Risk Management Framework 1.0 — AI risk yönetimi, hesap verebilirlik, yönetişim ve insan-AI etkileşiminin yapılandırılması.
- NIST Generative AI Profile — üretken AI için konfabülasyon, aşırı güven, bilgi bütünlüğü, gizlilik ve insan gözetimi.
- OWASP Top 10 for LLM Applications 2025 — hassas bilgi ifşası, yanlış bilgi, aşırı yetki ve LLM uygulamalarının operasyonel riskleri.
- DORA State of AI-assisted Software Development 2025 — temkinli bir çerçeve: AI mevcut örgütsel uygulamaları güçlendirir, tek başına teslimat iyileşmesini garanti etmez.
- Lehtinen, Itkonen & Lassenius: Recurring opinions or productive improvements? — retrospektifler, katılımcı yanlılığı, somut kanıt ve tekrar eden konular üzerine ampirik bir araştırma.
- Amy Edmondson: Psychological Safety and Learning Behavior in Work Teams — psikolojik güvenliğin takım öğrenmesinin bir koşulu olarak ele alındığı klasik kaynak.
- EDPB Opinion 28/2024 ve ICO monitoring at work guidance impact assessment — kişisel veriler, şeffaflık, ölçülülük ve işyeri izlemenin sınırlarına ilişkin kılavuzlar.
