Sprint Review ve AI: demo neden değer konuşmasının yerini almaz

Bu, AI'nin çapraz fonksiyonlu geliştirme ekibinin klasik toplantılarını nasıl değiştirdiğine dair serinin dördüncü makalesi. İlk makalede Backlog Refinement konusunu ele aldım ve AI'nin materyal hazırlığını hızlandırdığını, ancak anlamın ekip tarafından kontrolünün yerini almadığını gösterdim. İkincisinde Sprint Planningkonuşuldu: AI plan taslağını hazırlar, ancak ekip taahhüdünü üstlenmez. Üçüncüsünde ise Daily Scrum: AI sprintin gidişatına dair sinyaller hazırlar, ancak ekip adına senkronizasyonu yürütmez. Şimdi Sprint Review'a geçmek ve en cazip hatayı ele almak mantıklı: değer üzerine canlı bir konuşmayı güzel bir AI demosuna dönüştürmek.

Sprint Review, AI için ideal bir yer gibi görünüyor. Sprintin sonunda etkileyici bir sunum hazırlamak için gereken her şey zaten var: Jira'da kapatılmış görevler, birleştirilmiş pull request'ler, koddaki değişiklikler, yeni ekranlar, güncellenmiş metrikler, destek biletleri, kullanıcı geri bildirimleri. AI dakikalar içinde release notes hazırlayabilir, bir demo senaryosu taslaklayabilir, slaytları düzenleyebilir, toplamda ne kadar iş yapıldığını hesaplayabilir ve hatta kullanıcıların söylediklerinin düzgün bir özetini üretebilir.

İlk bakışta bu saf bir kazanç. Daha az manuel hazırlık. Daha az "toplantıdan beş dakika önce ne göstereceğimize karar verelim". Daha az sıkıcı yapılanlar listesi. Sunum profesyonel görünüyor, release notes tutarlı yazılmış, metrikler güzelce görselleştirilmiş.

Ama burada bir tuzak var ve Daily Scrum'dakinden daha ciddi.

Sprint Review gösteri için var değildir. Görevi, paydaşlarla birlikte sprintin sonucunu incelemek, Product Goal'a doğru ilerlemeyi tartışmak ve Product Backlog'u uyarlamaktır. AI, Sprint Review'u cilalı bir demoya dönüştürürse ekip daha güzel bir sunum elde eder, ama en önemlisini kaybeder: dürüst geri bildirimi, "bundan sonra ne yapmalı" konusunda ortak kararı ve ürüne dair sorumluluğu.

"AI hazırlık rutinini ortadan kaldırabilir, ama Sprint Review demo ile değil, üründe neyi değiştireceğine dair kararla değerlidir."

Sprint Review neden gerekli

Şu: Scrum Guide 2020 Sprint Review oldukça katı biçimde tanımlanmıştır. Bu, sprintin sondan ikinci etkinliğidir ve bir aylık sprint için en fazla dört saatlik timebox'a sahiptir. Amacı, sprintin sonucunu incelemek ve sonraki uyarlamaları belirlemektir. Scrum Team, çalışmanın sonuçlarını kilit paydaşlara sunar ve Product Goal'a doğru ilerleme tartışılır. Ayrıca, neredeyse tartışmalı bir biçimde, Scrum Guide şunu netleştirir: "The Sprint Review is a working session and the Scrum Team should avoid limiting it to a presentation" — bu bir çalışma oturumudur ve ekip bunu bir sunuma indirgemekten kaçınmalıdır.

Bu, tüm makale için anahtar ifadedir. Sprint Review, işin Product Owner tarafından kabulü, yönetime rapor, müşteri için pazarlama demosu ya da "biz harikayız" töreni değildir. Bu, ekibin ve paydaşların birlikte neyin yapıldığına ve çevrede nelerin değiştiğine bakıp bundan sonra ne yapılacağına karar verdiği andır. Etkinliğin sonucu alkışlar değil, güncellenmiş Product Backlog'dur.

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 companion kaynak olarak. Bu makale için pratik bir çerçeve olarak önemlidir: Sprint Review, paydaşlara gerçek değer akışı ve ürün planının ortak uyarlanmasıyla ilgilidir, durum sunumuyla değil. AI bölümünde modeli supervised decision-making partner olarak tanımlar: AI şeffaflığı, incelemeyi ve uyarlamayı güçlendirebilir, ancak insan sorumluluğunun yerini almaz ve sürecin ampirik kontrolünü ortadan kaldırmaz.

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

• sprintin gerçek sonucunun, onun hakkında anlatılan bir hikâye değil, incelenmesi;
• paydaşlardan ve kullanıcılardan dürüst geri bildirim toplanması;
• Product Goal'a doğru ilerlemenin kontrolü;
• bundan sonra ne yapılacağına dair ortak karar;
• sadece yapılanların gösterilmesi değil, Product Backlog'un uyarlanması.

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

Genellikle neler yanlış gider

Sprint Review'ın sorunu nadiren ekibin yapılanları göstermeyi bilmemesidir. Sorun, etkinliğin zamanla tek yönlü bir demoya dönüşmesidir: ekip bir sunum hazırlar, ekranları gösterir, kapatılan görevleri sıralar, paydaşlar kibarca başlarını sallar, biri "harika, teşekkürler" der ve herkes dağılır. Backlog ise değişmez. Scrum.org bu anti-pattern'i doğrudan şu materyalde ele alıyor: Myth 12: The Sprint Review is a Demo: demo etkinliğin bir parçası olabilir, ancak Sprint Review'ın amacı geri bildirimi en üst düzeye çıkarmak ve riski azaltmaktır, sunum yapmak değil.

O zaman toplantı kendi amacına karşı çalışmaya başlar. Ekip neyin tartışılması gerektiğini değil, nasıl daha güzel gösterileceğini tartışır. Paydaşlar geri bildirim vermeye zaman bulamaz çünkü ekip "kendi sunumuna safça kapılmıştır" — Scrum.org bunu materyalde ayrıca belirtiyor How to Engage Stakeholders in your Sprint Reviews. Rahatsız edici sorular sorulmaz. İnşa edilen ile pazarın ihtiyaç duyduğu şey arasındaki fark geç ortaya çıkar. Product Backlog, toplantıdan önceki haliyle kalır, oysa etkinliğin tüm amacı onu yeni verilere dayanarak değiştirmektir.

AI destekli bağlamda bu sorun daha da güçlenebilir. Model her sprintte bir sunum, release notes ve başarılar listesi üretirse, ekip kısa sürede "inceleme zaten hazır" düşüncesine alışır. O zaman Sprint Review daha da pürüzsüz hale gelir: AI slaytları açıldı, release notes okundu, metrikler gösterildi, kibar bir "teşekkürler" alındı ve toplantı kapatıldı.

Profesyonel görünüyor. Ama soru sunumun ne kadar tutarlı toplandığı değil. Soru, gerçeklik değiştiyse ekibin Product Backlog'unu değiştirip değiştirmediğidir.

AI gerçekte nerede yardımcı olur

AI'ın Sprint Review'da oldukça pratik bir fayda alanı vardır. Hazırlık rutinini ortadan kaldırabilir ve ekibin sprint sonunda kolayca kaybettiği şeyleri yüzeye çıkarabilir. Bu, kaynakların çok olduğu durumlarda özellikle değerlidir: issue tracker, pull request'ler, CI/CD, ürün analitiği, destek ticket'ları, mağaza yorumları, anket sonuçları, kullanıcı görüşme kayıtları.

Ama burada fazla söz vermemek önemli. En güncel DORA State of AI-assisted Software Development 2025 bile AI'ı daha iyi delivery için bağımsız bir garanti olarak değil, mevcut organizasyonel pratiklerin bir güçlendiricisi olarak tanımlıyor. Sprint Review için bu basit bir anlama gelir: ekip zaten değer üzerine dürüst bir konuşma yürütmeyi ve backlog'u uyarlamayı biliyorsa, AI bu konuşmaya girişi zenginleştirir. Sprint Review uzun zamandır bir demo ritüeline dönüşmüşse, AI bu ritüeli sadece daha hızlı ve daha güzel yapar.

İyi bir AI yardımcısı Sprint Review öncesinde "nasıl daha etkileyici gösterilir" değil, ürün kararı için faydalı bağlam toplar:

• sprint boyunca üründe gerçekte ne değişti ve bunun Product Goal ile nasıl bir bağlantısı var;
• incrementin hangi öğeleri incelemeye hazır, hangileri dürüstçe tamamlanmamış olarak gösterilmeli;
• önceki sürümlerden sonra ürün metrikleri ne söylüyor;
• kullanıcılardan ve destekten hangi geri bildirim geldi, çelişkili ve rahatsız edici olanlar dahil;
• önceki sprintlerin hangi hipotezleri doğrulandı, hangileri doğrulanmadı;
• hangi açık ürün soruları paydaşlarla tartışmaya taşınmalı;
• Product Backlog'daki hangi maddeler güncelliğini yitirmiş olabilir ya da tam tersine öncelik kazanmış olabilir.

Bu modda AI, Sprint Review'ın yerini almaz. Ona hazırlanmanın maliyetini düşürür. Ekip ham verilerle ya da aceleyle toplanmış slaytlarla değil, zaten yapılandırılmış bir tabloyla gelir: işte sonuç, işte veriler, işte geri bildirim, işte açık sorular. Bu, gerçekleri toplamaya daha az, "şimdi üründe neyi değiştiriyoruz?" konuşmasına daha çok zaman harcamayı sağlar.

Bu, serinin önceki makalelerinin mantığını sürdürüyor. Refinement'ta AI tartışma malzemesini toplamaya yardımcı oluyordu. Planning'de plan seçeneklerini. Daily Scrum'da sprintin gidişatına dair sinyalleri. Sprint Review'da ise sonucu ve geri bildirimi toplayabilir. Ancak dört durumda da insani kısım ortadan kalkmaz: ekip ve paydaşlar neyin önemli olduğunu, neyin değiştiğini ve hangi kararın alınması gerektiğini doğrulamalıdır.

AI neden Sprint Review'ı bir demo tiyatrosuna dönüştürmemeli

AI destekli Sprint Review'ın en tehlikeli versiyonu çok ikna edici görünür: model güzel slaytlar içeren bir sunum, tutarlı release notes, "sprintin kilit başarıları" listesi, metrik grafikleri ve kullanıcı geri bildiriminin pürüzsüz bir özetini üretir. Bazen Product Goal için otomatik bir tahmin ve backlog'da önerilen değişiklikler de eklenir.

Biçimsel şeffaflık açısından bu kullanışlıdır. Scrum açısından ise bu bir bozulma olabilir.

Birincisi, böyle bir format tek yönlülüğü güçlendirir. AI demosu ne kadar güzelse, toplantıyı bir sunum gibi "yönetme" cazibesi o kadar güçlenir. Dikkat geri bildirimden gösterime kayar: ekip slaytları savunur, paydaşları değer üzerine tartışmaya davet etmez.

İkincisi, AI'ın geri bildirim özeti tam da Sprint Review'ın yapılma amacını silebilir. Geri bildirimin gerçek değeri çelişkilerde, zayıf sinyallerde, rahatsız edici anlaşmazlıklarda ve nadir ama önemli yorumlardadır. Pürüzsüz ortalaması alınmış bir özet aykırı değerleri kolayca dışarı atar, oysa üründe çoğu zaman tam da aykırı değer bir sinyaldir. Bu, NIST'in üretken yapay zeka profili.

Üçüncü olarak, model verilerde olmayan içgörüleri kendinden emin bir şekilde uydurabilir. Konfabulasyon özellikle Sprint Review'da tehlikelidir, çünkü kullanıcılar hakkında üretilen "sonuç" kolayca bir ürün kararına dönüşür. AI "kullanıcılar X istiyor" diye yazdığında, ama gerçekte bu iki ticket ve bir görüşmeyse, ekip Product Backlog'u bir halüsinasyona dayanarak değiştirme riski taşır.

Dördüncü olarak, ekip ürün yargısını araca devretmeye başlayabilir. AI backlog'da değişiklik önerdiyse, bunların basitçe kabul edilebileceği görünür. AI Product Goal'a ulaşıldığını söylediyse, tartışılacak bir şey yokmuş gibi görünür. Bu, Sprint Review'ın otomasyonu değil, sorumluluğun olamayacağı yere taşınmasıdır: üründen model değil, Ürün Sahibi ve ekibi sorumludur.

"AI demosu faydalı bir girdi olabilir. Değer hakkındaki konuşmanın yerini almamalıdır."

Vaka çalışmasına devam edelim: B2B LMS ve e-posta hatırlatmaları

Önceki makalelerdeki 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, son tarihe kadar tamamlanmamış zorunlu kursu olan aktif çalışanlara tek bir doğru hatırlatma gönderir ve doğrulanabilir gönderim geçmişini saklar.

AI olmadan böyle bir sprintte Sprint Review kolayca demoya kayabilir. Ekip hatırlatma ayar ekranını gösterir, test e-postasını gösterir, "zamanlayıcı çalışıyor, tekilleştirme yerinde, geçmiş günlüğü yazılıyor" der, paydaşlar başını sallar, biri e-posta tasarımını över. Biçimsel olarak her şey iyi. Backlog değişmez.

Ama ekip en önemli şeyi atlayabilir: hatırlatmalar gidiyor, ama konu satırı kötü olduğu için açılma oranı düşük; destek ekibi zaten birkaç "zorunlu olmadığım bir kurs için neden hatırlatma aldım" başvurusu almış — yani eligibility sınırı beklenildiği gibi çalışmıyor; büyük bir müşteri bireysel zamanlama istiyor ve bu potansiyel olarak sonraki sprintin önceliklerini değiştiriyor; ve durumun yorumu expired, ekibin kapsam dışı saydığı, aslında paydaşlar için önemli.

AI burada yardımcı olabilir. Sprint Review öncesinde girdiyi toplar: ne gönderildi ve kime, açılma ve tıklama oranı ne, destek ekibine hangi başvurular geldi ve ne hakkında, pilot müşteriler hangi geri bildirimleri bıraktı, bu Sprint Goal ile hangi backlog maddeleri ilişkili. Bu, konuşma için iyi bir malzeme.

Ama değer ancak toplantıda, ekip ve paydaşlar bir sonraki adımı attığında ortaya çıkar: düşük açılma oranının kozmetik değil ürün sorunu olduğuna karar verirler; eligibility sınırının netleştirilmesi ve backlog'a ayrı bir madde olarak eklenmesi gerektiğine; büyük müşteriler için bireysel zamanlamaların hızlı bir düzeltme değil stratejik bir karar olduğuna; ve yorumun expired "kapsam dışı"ndan en yakın önceliğe taşınma zamanı. AI sonucu ve verileri verdi. Ekip paydaşlarla birlikte Product Backlog'u uyarladı.

Anti-patterns

Aşağıda, AI'ın Sprint Review'a entegrasyonunda özellikle izleyeceğim birkaç anti-pattern var.

1. AI sunumu güzelleştirir, ama toplantı tek yönlü kalır

Eğer çaba slaytları ve release notes'u parlatmaya gidiyorsa, Sprint Review bir working session olarak değil, demo olarak güçlenir. AI'ın sadece etkileyici bir yapılanlar gösterisi değil, paydaşlara sorular ve açık ürün konuları hazırlaması daha faydalıdır.

2. AI geri bildirim özeti ortalamayı alır ve zayıf sinyalleri kaybeder

Pürüzsüz özet okuması kolaydır, ama çelişkileri ve nadir ama önemli yorumları attığı için tehlikelidir. Geri bildirim, sadece ortalanmış "genel hava" değil, anlaşmazlık ve aykırı değerler korunarak getirilmelidir.

3. AI verilerde olmayan ürün içgörüleri uydurur

"Kullanıcılar X istiyor" ikna edici gelir, ama doğrulama gerektirir: sonuç kaç sinyale dayanıyor, bu bir halüsinasyon mu, nadir bir durumu kitlesel taleple mi değiştirdi. Modelden gelen içgörü bir hipotezdir, karar değil.

4. Metrikler karar için vesile değil, başarı olarak gösterilir

"10 000 e-posta gönderdik" bir aktivitedir, değer değil. Sprint Review metrikleri Product Goal ile ilişkilendirmeli ve planda neyi değiştirdiklerini sormalı, sprintin iyi geçtiğinin kanıtı olarak kullanmamalıdır.

5. AI Product Backlog'da değişiklik önerir ve bunlar tartışılmadan kabul edilir

Modelin önerisi faydalı bir girdi olabilir, ama backlog'un uyarlanması Ürün Sahibi'nin ekip ve paydaşlarla birlikte aldığı bir ürün kararıdır, AI önerilerinin otomatik uygulanması değil.

6. Uyarlama için inceleme yerine yönetim için demo tiyatrosu

Sprint Review "patrona ne kadar iyi olduğumuzu gösterelim" şovuna dönüşürse, AI sadece şovu daha ikna edici yapar. Bu, etkinliğe güveni zedeler ve ekibi dürüst geri bildirimden mahrum bırakır.

Roller nasıl değişecek

AI, Scrum Team içindeki rolleri ortadan kaldırmaz, ama Sprint Review hazırlığı ve yürütülmesindeki vurguyu değiştirir. Sunumu elle birleştirmede daha az değer var. Sonucun dürüst incelenmesinde, geri bildirimle çalışmada ve ürün hakkında ortak kararda daha fazla değer var.

Rol	Kötü AI senaryosunda risk	Olgun AI kullanımı
Ürün Sahibi	AI geri bildirim özetini ve önerilen backlog değişikliklerini hazır bir çözüm olarak kabul eder ve değeri kendisi düşünmeyi bırakır.	AI girdisini malzeme olarak kullanır, ancak değer konuşmasını kendisi yürütür, içgörüleri doğrular ve Product Backlog'un uyarlanmasından sorumludur.
Geliştiriciler	üretken yapay zeka için NIST profili	Sonucu ve riskleri hızlıca toplamak için AI kullanır ve artışı paydaşlarla birlikte dürüstçe inceler.
Scrum Master	Kolaylaştırıcılığı slaytlara devreder ve yalnızca sunumun zamanlamasını takip eder.	Sprint Review'u demoya dönüşmekten korur, paydaşların katılımına yardımcı olur ve odağı uyarlamada tutar.
Paydaşlar	Pürüzsüz bir AI demosu alır, kibarca başını sallar ve gerçek geri bildirim vermez.	Gerçek sonucu ve verileri görür, rahatsız edici sorular sorar ve ürün önceliklerini etkiler.
Kalite mühendisi / QA mühendisi	AI'nın "yapıldı" listesini onaylar ve artışın hazır olduğu izlenimini yaratır.	Neyin Definition of Done'a uyduğunu, neyin uymadığını ve kalite risklerinin nerede kaldığını dürüstçe göstermeye yardımcı olur.
UX/UI tasarımcısı	AI demosu işlevlere ve metriklere odaklandığı için gözden kaçar.	Kullanıcı gözlemlerini ve deneyim geri bildirimini getirir, sonucu gerçek değerle ilişkilendirmeye yardımcı olur.

AI destekli Sprint Review için pratik bir filtre

Ben "AI demo üreticisi" uygulamaya başlamazdım. Daha dar bir soruyla başlardım: hangi girdi, ekibin ve paydaşların dürüst bir ürün kararını daha hızlı almasına yardımcı olur? Bundan sonra AI, etkinliğin yerine geçen bir şey değil, bir hazırlık katmanı olarak kullanılabilir.

AI girdisi Sprint Review'da şu soruları yanıtlamaya yardımcı oluyorsa faydalıdır:

• Üründe gerçekte ne değişti ve bu Product Goal ile nasıl ilişkili?
• Neyin dürüst incelemeye hazır olduğu, neyin tamamlanmamış olarak gösterilmesi gerektiği?
• Veriler ve geri bildirim, çelişkili olanlar dahil, ne söylüyor?
• Hangi hipotezler doğrulandı, hangileri başarısız oldu?
• Paydaşlarla tartışılması gereken açık ürün soruları neler?
• Product Backlog'da hangi maddeler değiştirilmeli, eklenmeli veya çıkarılmalı?
• Sadece ne göstereceğimiz değil, sonuç olarak hangi kararı alacağız?

Tam tersine: AI girdisi esas olarak "yapılanı nasıl daha etkileyici gösteririz" sorusunu yanıtlıyorsa, bu Sprint Review değildir. Bu bir demodur. İletişim için faydalı olabilir, ancak sonucun incelenmesi ve Product Backlog'un uyarlanmasıyla karıştırılmamalıdır.

Veri yönetimi ve hijyeni

Sprint Review verilere özellikle duyarlıdır, çünkü AI hazırlığı kolayca destek biletlerinden, CRM'den, görüşme kayıtlarından, anketlerden, mağaza yorumlarından ve müşteri yazışmalarından geri bildirim toplamaya başlar. Erişim ne kadar genişse özet o kadar ikna edici olur. Ancak hassas bilgilerin sızması, anlamın çarpıtılması ve modelin kendinden emin ama eksik çıkarımına aşırı bağımlılık riski de o kadar yükselir. Bu risk sınıfları şurada iyi tanımlanmıştır: üretken yapay zeka için NIST profili, NIST Yapay Zeka Risk Yönetimi Çerçevesi 1.0 ve OWASP Top 10 for LLM Applications 2025.

Ekip, hangi geri bildirim kaynaklarının AI için izinli olduğunu, kullanıcı verilerinin nasıl anonimleştirildiğini, oluşturulan özeti kimin gördüğünü ve müşterilerin ham alıntılarının dış paydaşlara gösterilip gösterilemeyeceğini önceden kararlaştırmalıdır. Kullanıcıların ve müşterilerin kişisel verileriyle çalışırken şu tür referanslar faydalıdır: EDPB Opinion 28/2024 ve ICO monitoring at work impact assessment — makale için hukuki bir talimat olarak değil, hukuki dayanak, veri minimizasyonu, şeffaflık ve ölçülülük konusunda bir hatırlatma olarak.

Pratikte bu şu anlama gelir: modele gereksiz kişisel veri çekmemek, olguları üretilmiş yorumlardan ayırmak, AI içgörülerini hipotez olarak işaretlemek, kullanıcı alıntılarını birincil kaynaktan doğrulamak ve Sprint Review'da verilerle kanıtlanamayan "sonuçlar" göstermemek. AI, ekibin sonucu ve geri bildirimi dürüstçe görmesine yardımcı olmalı, ikna edici ama doğrulanmamış bir tablo üretmemelidir.

Pratik sonuç

AI gerçekten Sprint Review'u daha faydalı hale getirebilir. Hazırlık rutinini ortadan kaldırabilir, sprint sonucunu önceden toplayabilir, onu metriklerle ilişkilendirebilir, geri bildirimi bir araya getirebilir, plan ile gerçeklik arasındaki farkları vurgulayabilir ve paydaşlarla tartışılacak konular önerebilir.

Ancak bu yalnızca ekip sınırı anlarsa işe yarar: AI girdiyi hazırlar, Sprint Review'u yürütmez. Sonucu ve verileri görmeye yardımcı olur, ancak bunların ürün için ne anlama geldiğine karar vermez. Geri bildirimi toplayabilir, ancak değer üzerine dürüst bir konuşmayı kendi başına yaratmaz. Backlog'da değişiklik önerebilir, ancak ürünün sorumluluğunu üstlenmez.

Bu nedenle ana tezi şöyle formüle ederdim: AI hazırlık maliyetini azaltmalı ki ekip ve paydaşlar değer konuşmasına ve planın uyarlanmasına daha fazla dikkat ayırabilsin. Bunun tersi olur ve Sprint Review cilalı bir AI demosuna dönüşürse, ekip etkinliğin var olma nedenini tam da kaybeder: sonucun dürüst incelenmesi, gerçek geri bildirim, ortak karar ve ürün sorumluluğu.

Olgun bir ekip şunu sormaz: «Sprint incelemesini AI'ya yaptırabilir miyiz?». Farklı sorar: «Hazırlık rutininin hangi kısmını AI kaldırabilir ki Sprint Review'umuz değer ve üründe neyi değiştirmek gerektiği üzerine daha dürüst bir konuşma olsun?». Bu daha az gösterişli bir ifade. Ama gerçek ürün pratiğine daha yakın.

Kaynaklar ve referanslar

• Scrum Guide 2020 — Sprint Review, Product Goal, Product Backlog, artım, working session, inceleme ve uyarlama.
• Scrum Guide Expanded v2026.1 — Scrum Guide 2020 temelli tamamlayıcı kaynak: Sprint Review'ın pratik çerçevesi, paydaşlara değer akışı ve supervised decision-making partner olarak AI.
• Scrum.org: What is a Sprint Review? — Sprint Review'ın sunum değil, collaborative working session olması.
• Scrum.org: Myth 12 — The Sprint Review is a Demo — Sprint Review'ın neden bir demo'ya indirgenmemesi gerektiği.
• Scrum.org: How to Engage Stakeholders in your Sprint Reviews — paydaş geri bildiriminin etkinliğin temel değeri olmasının nedeni.
• NIST'in üretken yapay zekâ profili — konfabülasyon / kendinden emin uydurma, information integrity, aşırı bağımlılık ve insan kontrolü.
• NIST Yapay Zekâ Risk Yönetimi Çerçevesi 1.0 — yönetişim / düzenleme, hesap verebilirlik ve insan-AI etkileşiminin yapılandırılması.
• OWASP Top 10 for LLM Applications 2025 — hassas bilgi ifşası, misinformation ve LLM uygulamalarında excessive agency.
• DORA State of AI-assisted Software Development 2025 — AI'ın örgütsel pratikleri güçlendiren bir unsur olarak, iyileşmenin bağımsız garantisi değil.
• EDPB Opinion 28/2024 ve ICO monitoring at work impact assessment — geri bildirimle çalışırken kişisel veriler, minimizasyon, şeffaflık ve ölçülülük konusunda referanslar.