Sprint Review dan AI: mengapa demo tidak menggantikan percakapan tentang nilai

Ini adalah artikel keempat dari seri tentang bagaimana AI mengubah rapat klasik tim pengembangan lintas fungsi. Di artikel pertama saya membahas Backlog Refinement dan menunjukkan bahwa AI mempercepat persiapan materi, tetapi tidak menggantikan pemeriksaan makna oleh tim. Di artikel kedua dibahas Sprint Planning: AI menyusun draf rencana, tetapi tidak mengambil komitmen tim. Di artikel ketiga — tentang Daily Scrum: AI menyiapkan sinyal tentang jalannya sprint, tetapi tidak melakukan sinkronisasi untuk tim. Sekarang logis untuk beralih ke Sprint Review dan membahas kesalahan paling menggoda: mengubah percakapan hidup tentang nilai menjadi demo AI yang indah.

Sprint Review tampak seperti tempat ideal untuk AI. Di akhir sprint sudah ada semua yang mudah dirakit menjadi presentasi yang mengesankan: tugas yang selesai di Jira, pull request yang sudah di-merge, perubahan kode, layar baru, metrik yang diperbarui, tiket dukungan, umpan balik pengguna. AI dapat dalam hitungan menit menyusun release notes, membuat draf skenario demo, merapikan slide, menghitung berapa banyak yang telah dikerjakan, dan bahkan menghasilkan ringkasan rapi tentang apa yang dikatakan pengguna.

Sekilas ini keuntungan murni. Lebih sedikit persiapan manual. Lebih sedikit "mari kita putuskan lima menit sebelum rapat apa yang akan ditampilkan". Lebih sedikit penomoran membosankan tentang apa yang telah dilakukan. Presentasi terlihat profesional, release notes ditulis dengan runtut, metrik divisualisasikan dengan indah.

Tetapi di sini ada jebakan, dan ini lebih serius daripada di Daily Scrum.

Sprint Review ada bukan untuk demonstrasi. Tugasnya adalah bersama pemangku kepentingan menginspeksi hasil sprint, membahas kemajuan menuju Product Goal, dan mengadaptasi Product Backlog. Jika AI mengubah Sprint Review menjadi demo yang dipoles, tim mendapatkan presentasi yang lebih indah, tetapi kehilangan hal utama: umpan balik yang jujur, keputusan bersama "apa yang harus dilakukan selanjutnya", dan tanggung jawab atas produk.

“AI dapat menghilangkan rutinitas persiapan, tetapi Sprint Review bernilai bukan karena demo, melainkan karena keputusan tentang apa yang harus diubah dalam produk.”

Mengapa Sprint Review diperlukan

Dalam Scrum Guide 2020 Sprint Review dijelaskan dengan cukup ketat. Ini adalah acara kedua dari belakang dalam sprint, timeboxed maksimal empat jam untuk sprint bulanan. Tujuannya adalah menginspeksi hasil sprint dan menentukan adaptasi selanjutnya. Scrum Team mempresentasikan hasil kerja kepada pemangku kepentingan utama, dan dibahas kemajuan menuju Product Goal. Dan secara terpisah, hampir polemis, Scrum Guide menegaskan: «The Sprint Review is a working session and the Scrum Team should avoid limiting it to a presentation» — ini adalah sesi kerja, dan tim sebaiknya tidak mereduksinya menjadi presentasi.

Ini adalah frasa kunci untuk seluruh artikel. Sprint Review bukan penerimaan kerja oleh Product Owner, bukan laporan kepada manajemen, bukan demo pemasaran untuk pelanggan, dan bukan seremoni "kita hebat". Ini adalah momen ketika tim dan pemangku kepentingan bersama-sama melihat apa yang telah dibuat dan apa yang berubah di sekitarnya, lalu memutuskan apa yang harus dilakukan selanjutnya. Hasil acara ini bukan tepuk tangan, melainkan Product Backlog yang disesuaikan.

Sebagai acuan tambahan, Scrum Guide Expanded v2026.1juga berguna, tetapi tepatnya sebagai sumber pendamping, bukan versi kanonik baru Scrum Guide. Untuk artikel ini ia penting sebagai kerangka praktis: Sprint Review adalah tentang aliran nilai nyata kepada pemangku kepentingan dan adaptasi bersama atas rencana produk, bukan tentang presentasi status. Di bagian tentang AI, ia menggambarkan model sebagai supervised decision-making partner: AI dapat memperkuat transparansi, inspeksi, dan adaptasi, tetapi tidak menggantikan tanggung jawab manusia dan tidak membatalkan kontrol empiris atas proses.

Karena itu saya akan menggambarkan tujuan Sprint Review melalui lima fungsi:

• inspeksi hasil nyata sprint, bukan cerita tentangnya;
• pengumpulan umpan balik yang jujur dari pemangku kepentingan dan pengguna;
• pemeriksaan kemajuan menuju Product Goal;
• keputusan bersama tentang apa yang harus dilakukan selanjutnya;
• adaptasi Product Backlog, bukan sekadar menunjukkan apa yang telah dibuat.

Ini adalah kerangka untuk percakapan tentang AI. Jika alat membantu tim menjalankan fungsi-fungsi ini dengan lebih baik, ia bermanfaat. Jika ia hanya membuat demo lebih indah, ia mungkin nyaman, tetapi belum tentu meningkatkan produk.

Apa yang biasanya salah

Masalah Sprint Review jarang terletak pada ketidakmampuan tim menunjukkan apa yang telah dibuat. Masalahnya adalah acara ini seiring waktu merosot menjadi demo satu arah: tim menyiapkan presentasi, menunjukkan layar, menomori tugas yang selesai, pemangku kepentingan mengangguk sopan, seseorang berkata "bagus, terima kasih", dan semua bubar. Backlog pun tidak berubah. Scrum.org secara langsung membahas anti-pattern ini dalam materi Myth 12: The Sprint Review is a Demo: demo bisa menjadi bagian dari acara, tetapi tujuan Sprint Review adalah memaksimalkan umpan balik dan mengurangi risiko, bukan menyelenggarakan presentasi.

Kemudian pertemuan mulai bekerja melawan tujuannya sendiri. Tim membahas bagaimana menampilkan dengan lebih indah, bukan apa yang penting untuk dibahas. Pemangku kepentingan tidak sempat memberikan umpan balik karena tim "secara naif tenggelam dalam presentasinya sendiri" — Scrum.org secara khusus mencatat hal ini dalam materi How to Engage Stakeholders in your Sprint Reviews. Pertanyaan-pertanyaan tidak nyaman tidak diajukan. Kesenjangan antara apa yang dibangun dan apa yang dibutuhkan pasar muncul terlambat. Product Backlog tetap sama seperti sebelum pertemuan, padahal seluruh makna acara ini adalah mengubahnya berdasarkan data baru.

Dalam konteks AI-assisted, masalah ini bisa diperkuat. Jika model setiap sprint menghasilkan presentasi, release notes, dan daftar pencapaian, tim cepat terbiasa dengan gagasan bahwa "tinjauan sudah disiapkan". Kemudian Sprint Review menjadi lebih mulus: membuka slide AI, membaca release notes, menunjukkan metrik, menerima "terima kasih" yang sopan, dan menutup pertemuan.

Terlihat profesional. Tetapi pertanyaannya bukan seberapa koheren presentasi disusun. Pertanyaannya adalah apakah tim mengubah Product Backlog mereka jika realitas berubah.

Di mana AI benar-benar membantu

AI dalam Sprint Review memiliki zona manfaat yang cukup praktis. Ia dapat menghilangkan rutinitas persiapan dan mengangkat ke permukaan hal-hal yang mudah hilang oleh tim di akhir sprint. Ini sangat berharga ketika sumbernya banyak: issue tracker, pull requests, CI/CD, analitik produk, tiket dukungan, ulasan dari toko aplikasi, hasil survei, rekaman wawancara pengguna.

Tetapi di sini penting untuk tidak menjanjikan berlebihan. Bahkan DORA State of AI-assisted Software Development 2025 yang terbaru menggambarkan AI lebih sebagai penguat praktik organisasi yang ada daripada sebagai jaminan mandiri untuk delivery yang lebih baik. Untuk Sprint Review ini berarti sederhana: jika tim sudah mampu melakukan percakapan jujur tentang nilai dan menyesuaikan backlog, AI akan membuat pintu masuk ke percakapan itu lebih kaya. Jika Sprint Review sudah lama menjadi ritual demo, AI hanya akan membuat ritual itu lebih cepat dan lebih indah.

Asisten AI yang baik sebelum Sprint Review mengumpulkan bukan "bagaimana menampilkan lebih mengesankan", melainkan konteks yang berguna untuk keputusan tentang produk:

• apa yang benar-benar berubah dalam produk selama sprint dan bagaimana kaitannya dengan Product Goal;
• elemen increment mana yang siap untuk inspeksi, dan mana yang lebih baik ditunjukkan dengan jujur sebagai belum selesai;
• apa yang dikatakan metrik produk setelah rilis sebelumnya;
• umpan balik apa yang datang dari pengguna dan dukungan, termasuk yang kontradiktif dan tidak nyaman;
• hipotesis sprint sebelumnya mana yang terkonfirmasi dan mana yang tidak;
• pertanyaan produk terbuka mana yang layak dibawa ke diskusi dengan pemangku kepentingan;
• item Product Backlog mana yang mungkin kehilangan relevansi atau sebaliknya naik prioritasnya.

Dalam mode seperti ini AI tidak menggantikan Sprint Review. Ia menurunkan biaya persiapan untuknya. Tim datang bukan dengan data mentah dan bukan dengan slide yang disusun terburu-buru, melainkan dengan gambaran yang sudah terstruktur: ini hasilnya, ini datanya, ini umpan baliknya, ini pertanyaan terbukanya. Ini memungkinkan menghabiskan lebih sedikit waktu untuk mengumpulkan fakta dan lebih banyak untuk percakapan "apa yang sekarang kita ubah dalam produk?".

Ini melanjutkan logika artikel-artikel sebelumnya dalam seri. Dalam refinement AI membantu mengumpulkan materi untuk diskusi. Dalam planning — varian rencana. Dalam Daily Scrum — sinyal tentang jalannya sprint. Dalam Sprint Review ia dapat mengumpulkan hasil dan umpan balik. Tetapi dalam keempat kasus tersebut bagian manusiawi tidak hilang: tim dan pemangku kepentingan harus memeriksa apa yang penting, apa yang berubah, dan keputusan apa yang harus diambil.

Mengapa AI tidak boleh mengubah Sprint Review menjadi teater demo

Versi paling berbahaya dari AI-assisted Sprint Review terlihat sangat meyakinkan: model menghasilkan presentasi dengan slide indah, release notes yang koheren, daftar "pencapaian kunci sprint", grafik metrik, dan ringkasan umpan balik pengguna yang mulus. Kadang ditambahkan prediksi otomatis terhadap Product Goal dan usulan perubahan pada backlog.

Dari sudut pandang transparansi formal ini nyaman. Dari sudut pandang Scrum ini bisa menjadi degradasi.

Pertama, format seperti ini memperkuat kesatuarahan. Semakin indah demo AI, semakin kuat godaan untuk "menyelenggarakan" pertemuan sebagai presentasi. Perhatian bergeser dari umpan balik ke pertunjukan: tim membela slide, bukan mengundang pemangku kepentingan untuk berdebat tentang nilai.

Kedua, ringkasan AI atas umpan balik dapat menghapus justru hal yang menjadi alasan Sprint Review diadakan. Nilai sejati umpan balik ada pada kontradiksi, sinyal lemah, ketidaksetujuan yang tidak nyaman, dan komentar langka namun penting. Ringkasan rata-rata yang mulus mudah membuang outlier, padahal dalam produk sering justru outlier itulah sinyalnya. Ini adalah risiko klasik information integrity dan misinformation yang dijelaskan dalam profil NIST untuk AI generatif.

Ketiga, model dapat dengan yakin mengarang insight yang tidak ada dalam data. Konfabulasi sangat berbahaya dalam Sprint Review, karena "kesimpulan" yang dihasilkan tentang pengguna mudah berubah menjadi keputusan produk. Jika AI menulis "pengguna meminta X", padahal sebenarnya itu hanya dua tiket dan satu wawancara, tim berisiko mengubah Product Backlog berdasarkan halusinasi.

Keempat, tim dapat mulai mendelegasikan pertimbangan produk kepada alat. Jika AI mengusulkan perubahan pada backlog, tampaknya itu bisa langsung diterima. Jika AI mengatakan Product Goal tercapai, tampaknya tidak ada yang perlu dibahas. Ini bukan otomatisasi Sprint Review, melainkan pemindahan tanggung jawab ke tempat yang seharusnya tidak ada tanggung jawab: produk adalah tanggung jawab Pemilik Produk bersama tim, bukan model.

"Demo AI bisa menjadi masukan yang berguna. Itu tidak boleh menjadi pengganti percakapan tentang nilai."

Mari lanjutkan kasusnya: LMS B2B dan pengingat email

Mari ambil kasus yang sama dari artikel sebelumnya: platform LMS B2B, kursus wajib, pengingat email kepada karyawan yang belum menyelesaikan kursus wajib sebelum tenggat. Pada planning, tim memilih Sprint Goal yang sempit: sistem mengirim satu pengingat yang benar kepada karyawan aktif dengan kursus wajib yang belum selesai sebelum tenggat dan menyimpan riwayat pengiriman yang dapat diverifikasi.

Tanpa AI, Sprint Review dalam sprint seperti ini bisa dengan mudah berubah menjadi demo. Tim menunjukkan layar pengaturan pengingat, mendemonstrasikan email uji, mengatakan "penjadwal berfungsi, deduplikasi sudah ada, log riwayat tercatat", para pemangku kepentingan mengangguk, seseorang memuji desain email. Secara formal semuanya baik. Backlog tidak berubah.

Tetapi tim bisa melewatkan hal utama: pengingat terkirim, tetapi tingkat buka rendah karena subjek email kurang tepat; layanan dukungan sudah menerima beberapa keluhan "mengapa saya menerima pengingat untuk kursus yang tidak wajib saya ikuti" — artinya batas eligibility bekerja tidak seperti yang diharapkan; satu klien besar meminta jadwal individual, dan ini berpotensi mengubah prioritas sprint berikutnya; dan interpretasi status expiredyang dianggap tim di luar cakupan pekerjaan, sebenarnya penting bagi pemangku kepentingan.

AI di sini dapat membantu. Sebelum Sprint Review, AI mengumpulkan masukan: apa yang dikirim dan kepada siapa, berapa tingkat buka dan klik, keluhan apa yang masuk ke dukungan dan tentang apa, umpan balik apa yang diberikan klien pilot, item backlog mana yang terkait dengan Sprint Goal ini. Ini bahan yang baik untuk percakapan.

Tetapi nilai muncul hanya pada pertemuan, ketika tim dan pemangku kepentingan mengambil langkah berikutnya: memutuskan bahwa tingkat buka rendah adalah masalah produk, bukan kosmetik; bahwa batas eligibility perlu diperjelas dan dimasukkan ke backlog sebagai item terpisah; bahwa jadwal individual untuk klien besar adalah keputusan strategis, bukan perbaikan cepat; dan bahwa interpretasi expired perlu dipindahkan dari "di luar cakupan pekerjaan" ke prioritas terdekat. AI memberikan hasil dan data. Tim bersama pemangku kepentingan mengadaptasi Product Backlog.

Anti-pattern

Berikut adalah beberapa anti-pattern yang akan saya pantau secara khusus saat menerapkan AI dalam Sprint Review.

1. AI membuat presentasi lebih indah, tetapi pertemuan tetap satu arah

Jika upaya dihabiskan untuk memoles slide dan release notes, Sprint Review menguat sebagai demo, bukan sebagai sesi kerja. Lebih berguna jika AI menyiapkan pertanyaan untuk pemangku kepentingan dan topik produk terbuka, bukan hanya pertunjukan yang mengesankan tentang apa yang telah dibuat.

2. Ringkasan umpan balik AI merata-ratakan dan kehilangan sinyal lemah

Ringkasan yang mulus nyaman dibaca, tetapi berbahaya karena membuang kontradiksi dan komentar yang jarang tetapi penting. Umpan balik sebaiknya dibawa dengan mempertahankan ketidaksetujuan dan outlier, bukan hanya "suasana umum" yang dirata-ratakan.

3. AI mengarang insight produk yang tidak ada dalam data

"Pengguna menginginkan X" terdengar meyakinkan, tetapi perlu diverifikasi: berapa banyak sinyal yang mendasari kesimpulan itu, apakah ini halusinasi, apakah ia menggantikan kasus langka dengan permintaan massal. Insight dari model adalah hipotesis, bukan keputusan.

4. Metrik ditampilkan sebagai pencapaian, bukan sebagai alasan untuk keputusan

"Mengirim 10.000 email" adalah aktivitas, bukan nilai. Sprint Review harus menghubungkan metrik dengan Product Goal dan menanyakan apa yang mereka ubah dalam rencana, bukan menggunakannya sebagai bukti bahwa sprint berjalan baik.

5. AI mengusulkan perubahan pada Product Backlog, dan itu diterima tanpa diskusi

Usulan model bisa menjadi masukan yang berguna, tetapi adaptasi backlog adalah keputusan produk Pemilik Produk bersama tim dan pemangku kepentingan, bukan penerapan otomatis rekomendasi AI.

6. Teater demo untuk manajemen alih-alih inspeksi untuk adaptasi

Jika Sprint Review berubah menjadi pertunjukan "tunjukkan kepada atasan bahwa kita hebat", AI hanya membuat pertunjukan lebih meyakinkan. Ini merusak kepercayaan pada acara tersebut dan menghilangkan umpan balik jujur dari tim.

Bagaimana peran akan berubah

AI tidak membatalkan peran dalam Scrum Team, tetapi mengubah penekanan dalam persiapan dan pelaksanaan Sprint Review. Lebih sedikit nilai dalam merakit presentasi secara manual. Lebih banyak nilai dalam inspeksi hasil yang jujur, bekerja dengan umpan balik, dan keputusan bersama tentang produk.

Peran	Risiko pada skenario AI yang buruk	Penggunaan AI yang matang
Pemilik Produk	Menerima ringkasan umpan balik AI dan perubahan backlog yang diusulkan sebagai solusi siap pakai dan berhenti memikirkan sendiri nilai.	Menggunakan masukan AI sebagai bahan, tetapi sendiri memimpin percakapan tentang nilai, memverifikasi wawasan, dan bertanggung jawab atas adaptasi Product Backlog.
Pengembang	Menghabiskan persiapan untuk memoles demo AI alih-alih menunjukkan secara jujur apa yang sudah siap dan apa yang belum.	Menggunakan AI untuk dengan cepat mengumpulkan hasil dan risiko, dan secara jujur menginspeksi increment bersama pemangku kepentingan.
Scrum Master	Menyerahkan fasilitasi ke slide dan hanya memantau waktu presentasi.	Melindungi Sprint Review dari berubah menjadi demo, membantu melibatkan pemangku kepentingan dan menjaga fokus pada adaptasi.
Pemangku kepentingan	Mendapatkan demo AI yang mulus, mengangguk sopan, dan tidak memberikan umpan balik yang sebenarnya.	Melihat hasil dan data yang jujur, mengajukan pertanyaan yang tidak nyaman, dan memengaruhi prioritas produk.
Insinyur kualitas / QA engineer	Mengonfirmasi daftar "selesai" dari AI dan menciptakan kesan bahwa increment sudah siap.	Membantu menunjukkan secara jujur apa yang sesuai dengan Definition of Done dan apa yang tidak, serta di mana risiko kualitas masih tersisa.
Desainer UX/UI	Tersisih dari tinjauan karena demo AI berfokus pada fitur dan metrik.	Membawa observasi pengguna dan umpan balik tentang pengalaman, membantu menghubungkan hasil dengan nilai nyata.

Filter praktis untuk Sprint Review berbantuan AI

Saya tidak akan memulai dengan menerapkan "generator demo AI". Saya akan memulai dengan pertanyaan yang lebih sempit: masukan apa yang membantu tim dan pemangku kepentingan lebih cepat mengambil keputusan produk yang jujur? Setelah itu AI dapat digunakan sebagai lapisan persiapan, bukan sebagai pengganti event.

Masukan AI untuk Sprint Review berguna jika membantu menjawab pertanyaan:

• Apa yang benar-benar berubah dalam produk dan bagaimana kaitannya dengan Product Goal?
• Apa yang siap untuk inspeksi jujur, dan apa yang perlu ditunjukkan sebagai belum selesai?
• Apa yang dikatakan data dan umpan balik, termasuk yang kontradiktif?
• Hipotesis mana yang terkonfirmasi dan mana yang gagal?
• Pertanyaan produk terbuka apa yang perlu dibahas dengan pemangku kepentingan?
• Item Product Backlog mana yang perlu diubah, ditambahkan, atau dihapus?
• Keputusan apa yang akan kita ambil berdasarkan hasilnya, bukan sekadar apa yang akan kita tampilkan?

Dan sebaliknya: jika masukan AI terutama menjawab pertanyaan "bagaimana menampilkan yang sudah dikerjakan dengan lebih mengesankan", itu bukan Sprint Review. Itu demo. Itu bisa berguna untuk komunikasi, tetapi jangan sampai tertukar dengan inspeksi hasil dan adaptasi Product Backlog.

Tata kelola dan higiene data

Sprint Review sangat sensitif terhadap data, karena persiapan AI mudah mulai mengumpulkan umpan balik dari tiket dukungan, CRM, rekaman wawancara, survei, ulasan di toko aplikasi, dan korespondensi dengan pelanggan. Semakin luas aksesnya, semakin meyakinkan ringkasannya. Tetapi semakin tinggi risiko kebocoran informasi sensitif, distorsi makna, dan ketergantungan berlebihan pada kesimpulan model yang percaya diri tetapi tidak lengkap. Kelas risiko ini dijelaskan dengan baik dalam profil NIST untuk AI generatif, dalam kerangka kerja NIST untuk manajemen risiko AI 1.0 dan dalam OWASP Top 10 for LLM Applications 2025.

Tim perlu menyepakati sebelumnya sumber umpan balik mana yang diizinkan untuk AI, bagaimana data pengguna dianonimkan, siapa yang melihat ringkasan yang dihasilkan, dan apakah kutipan mentah pelanggan boleh ditunjukkan kepada pemangku kepentingan eksternal. Saat bekerja dengan data pribadi pengguna dan pelanggan, pedoman seperti EDPB Opinion 28/2024 dan ICO monitoring at work impact assessment berguna — bukan sebagai instruksi hukum untuk artikel, tetapi sebagai pengingat tentang dasar hukum, minimalisasi data, transparansi, dan proporsionalitas.

Secara praktis ini berarti: jangan menarik data pribadi yang tidak perlu ke dalam model, pisahkan fakta dari interpretasi yang dihasilkan, tandai wawasan AI sebagai hipotesis, verifikasi kutipan pengguna dengan sumber aslinya, dan jangan tampilkan di Sprint Review "kesimpulan" yang tidak dapat dikonfirmasi dengan data. AI harus membantu tim melihat hasil dan umpan balik secara jujur, bukan menghasilkan gambaran yang meyakinkan tetapi tidak terverifikasi.

Kesimpulan praktis

AI memang dapat membuat Sprint Review lebih berguna. AI dapat menghilangkan rutinitas persiapan, mengumpulkan hasil sprint terlebih dahulu, menghubungkannya dengan metrik, mengagregasi umpan balik, menyoroti kesenjangan antara rencana dan kenyataan, dan mengusulkan topik untuk dibahas dengan pemangku kepentingan.

Tetapi ini hanya berhasil jika tim memahami batasnya: AI menyiapkan masukan, bukan menyelenggarakan Sprint Review. AI membantu melihat hasil dan data, tetapi tidak memutuskan apa artinya bagi produk. AI dapat mengumpulkan umpan balik, tetapi tidak menciptakan percakapan jujur tentang nilai dengan sendirinya. AI dapat mengusulkan perubahan pada backlog, tetapi tidak mengambil tanggung jawab atas produk.

Oleh karena itu tesis utamanya saya rumuskan demikian: AI harus mengurangi biaya persiapan agar tim dan pemangku kepentingan memiliki lebih banyak perhatian untuk percakapan tentang nilai dan adaptasi rencana. Jika yang terjadi sebaliknya dan Sprint Review berubah menjadi demo AI yang dipoles, tim kehilangan justru hal yang menjadi alasan event itu ada: inspeksi hasil yang jujur, umpan balik yang sebenarnya, keputusan bersama, dan tanggung jawab atas produk.

Tim yang matang tidak bertanya: «bisakah kita menyerahkan kepada AI untuk menyusun tinjauan sprint?». Mereka bertanya dengan cara lain: «bagian rutinitas persiapan mana yang bisa dihilangkan AI agar Sprint Review kita menjadi percakapan yang lebih jujur tentang nilai dan tentang apa yang perlu diubah dalam produk?». Rumusan ini kurang memukau. Namun lebih dekat dengan praktik produk yang nyata.

Sumber dan acuan

• Scrum Guide 2020 — Sprint Review, Product Goal, Product Backlog, increment, working session, inspeksi dan adaptasi.
• Scrum Guide Expanded v2026.1 — sumber pendamping berbasis Scrum Guide 2020: practical framing Sprint Review, aliran nilai kepada stakeholder, dan AI sebagai supervised decision-making partner.
• Scrum.org: What is a Sprint Review? — Sprint Review sebagai collaborative working session, bukan presentasi.
• Scrum.org: Myth 12 — The Sprint Review is a Demo — mengapa Sprint Review tidak boleh direduksi menjadi demo.
• Scrum.org: How to Engage Stakeholders in your Sprint Reviews — mengapa umpan balik stakeholder adalah nilai utama dari event ini.
• profil NIST untuk AI generatif — konfabulasi / keyakinan palsu, information integrity, ketergantungan berlebihan, dan kontrol manusia.
• kerangka kerja NIST untuk manajemen risiko AI 1.0 — tata kelola / regulasi, akuntabilitas, dan konfigurasi interaksi manusia dan AI.
• OWASP Top 10 for LLM Applications 2025 — pengungkapan informasi sensitif, misinformation, dan excessive agency dalam aplikasi LLM.
• DORA State of AI-assisted Software Development 2025 — AI sebagai penguat praktik organisasi, bukan jaminan perbaikan yang berdiri sendiri.
• EDPB Opinion 28/2024 dan ICO monitoring at work impact assessment — acuan mengenai data pribadi, minimalisasi, transparansi, dan proporsionalitas saat bekerja dengan umpan balik.