← Esai

AI dan Scrum Events: apa yang sebenarnya berubah dalam rapat tim pengembangan

Ringkasan seri: bagaimana AI mengubah Scrum Events, di mana ia membantu tim, risiko apa yang diperkuatnya, dan mengapa tanggung jawab tetap ada pada manusia.

14 menit baca
TelegramAsli
AI dan Scrum Events: apa yang sebenarnya berubah dalam rapat tim pengembangan

Ini adalah artikel penutup dari seri tentang bagaimana AI mengubah rapat klasik tim pengembangan lintas fungsi. Di bagian-bagian sebelumnya saya membahas secara terpisah Backlog Refinement, Sprint Planning, Daily Scrum, Sprint Review dan Sprint Retrospective. Jika disatukan, kesimpulan umumnya cukup bijak: AI membuat persiapan untuk Scrum events lebih murah dan lebih kaya, tetapi tidak mengambil alih tanggung jawab tim atas inspeksi, adaptasi, percakapan, dan perubahan nyata.

Ketika saya memulai seri ini, mudah untuk terjebak dalam salah satu dari dua skenario ekstrem. Pertama: AI akan segera menggantikan hampir semua rapat tim, karena model sudah mampu meringkas, menulis tugas, menghasilkan rencana, mengumpulkan status, menyiapkan demo, dan mengusulkan action items. Kedua: Scrum events secara alami begitu manusiawi sehingga AI hampir tidak dibutuhkan di sana.

Setelah lima pembahasan terpisah, menurut saya kedua skenario itu terlalu dangkal.

AI memang mengubah rapat tim. Tetapi tidak seperti yang biasanya terdengar dalam janji-janji iklan. Ia mengubah bukan inti Scrum events, melainkan lapisan di sekitarnya: persiapan, pencarian, peringkasan, penstrukturan awal, deteksi sinyal, pencatatan keputusan, dan follow-up. Dan semakin murah lapisan ini, semakin terlihat apa yang tidak dapat diotomatisasi tanpa kehilangan makna: pertimbangan tim, tanggung jawab, perdebatan tentang nilai, verifikasi realitas, keamanan psikologis, dan kemampuan mengubah rencana, backlog, atau cara kerja.

“AI membuat persiapan lebih murah, tetapi membuat tanggung jawab manusia lebih terlihat.”

Itulah jawaban utama atas pertanyaan seri ini. AI tidak menghapus rapat klasik tim pengembangan lintas fungsi. Ia mengubah ekonomi perhatian mereka. Pengumpulan fakta rutin menjadi lebih murah. Produksi draf yang rapi menjadi lebih murah. Komunikasi status menjadi lebih murah. Tetapi nilai nyata dari peristiwa Scrum tetap muncul di tempat tim melihat fakta, berdebat tentang makna, menerima kompromi, dan mengubah tindakan selanjutnya.

Pertama, ada baiknya kembali ke tujuan rapat

Dalam Scrum Guide 2020 peristiwa Scrum dijelaskan bukan sebagai kumpulan ritual, melainkan sebagai peluang bawaan untuk transparansi, inspeksi, dan adaptasi. Sprint Planning memulai sprint dan membantu tim menyepakati nilai, cakupan pekerjaan, dan cara pelaksanaan. Daily Scrum dibutuhkan oleh Pengembang untuk memeriksa kemajuan menuju Sprint Goal dan mengadaptasi Sprint Backlog. Sprint Review dibutuhkan untuk menginspeksi hasil dan adaptasi lebih lanjut atas Product Backlog. Sprint Retrospective dibutuhkan untuk meningkatkan kualitas dan efektivitas kerja tim.

Backlog Refinement berdiri sendiri: ini bukan peristiwa Scrum resmi dalam Scrum Guide 2020, melainkan aktivitas berkelanjutan untuk memperjelas Product Backlog. Namun dalam kehidupan nyata tim lintas fungsi, refinement sering berfungsi sebagai rapat rutin penting atau rangkaian sesi kerja. Karena itu dalam seri ini saya membahasnya bersama peristiwa klasik: di sanalah tim pertama kali menghadapi volume besar persiapan intelektual manual yang mulai paling cepat dipercepat oleh AI.

Kerangka ini penting karena melindungi dari pertanyaan yang salah. Pertanyaan buruknya berbunyi: “rapat mana yang bisa digantikan AI?”. Pertanyaan yang lebih tepat: “bagian mana dari persiapan manual yang bisa diambil AI agar rapat itu sendiri menjadi inspeksi dan adaptasi yang lebih jujur?”.

Sebagai acuan tambahan dalam artikel-artikel terakhir seri ini saya menggunakan Scrum Guide Expanded v2026.1. Sumber ini sebaiknya dibaca sebagai sumber pendamping berbasis Scrum Guide 2020, bukan sebagai versi kanonik baru Scrum Guide. Untuk topik AI, rumusan model sebagai supervised decision-making partner berguna di sana: AI dapat memperkuat transparency, inspection, dan adaptation, tetapi tidak menggantikan human accountability dan tidak boleh menghapus empirical process control. Untuk artikel penutup ini, itu hampir merupakan batas yang ideal.

Apa yang berulang di kelima bagian

Dalam artikel tentang Backlog Refinement kesimpulan utamanya adalah: AI mempercepat bukan kesepakatan tim itu sendiri, melainkan persiapan materi untuknya. Ia membantu mengumpulkan konteks, draf user story, kriteria penerimaan, risiko, pertanyaan terbuka, dan opsi solusi awal. Tetapi ia juga menciptakan risiko kejelasan palsu: tugas tampak jelas karena diformat dengan baik.

Dalam artikel tentang Sprint Planning pola serupa muncul pada tingkat lain. AI membantu lebih cepat menyusun opsi Sprint Goal, cakupan pekerjaan, dependensi, dekomposisi, dan risiko. Tetapi muncul realisme palsu: rencana tampak koheren, lengkap, dan dapat dieksekusi, padahal tim belum memverifikasinya terhadap capacity, Definition of Done, keterujian, dan batasan nyata.

Dalam Daily Scrum AI tidak lagi menyiapkan pekerjaan masa depan, melainkan mengumpulkan sinyal tentang jalannya sprint. Ia dapat menyoroti blocker, review bottleneck, tes yang tidak stabil, ketidaksesuaian antara status Jira dan kenyataan, dependensi, dan keputusan yang diambil secara asinkron. Namun jika fokus bergeser dari Sprint Goal ke “siapa sibuk dengan apa”, Daily Scrum berubah menjadi AI-generated status reporting.

Di Sprint Review AI berguna sebagai lapisan persiapan untuk hasil sprint, metrik, release notes, umpan balik, dan pertanyaan produk yang terbuka. Namun di sana pula risiko demo theater paling terlihat: model membuat tinjauan menjadi indah, tim menampilkan cerita yang sudah dipoles, stakeholder mengangguk, tetapi Product Backlog tidak berubah.

Di Sprint Retrospective AI dapat membawa hard evidence ke dalam percakapan: impediment yang berulang, penantian review, action item yang tidak selesai, ketidaksesuaian dengan Definition of Done, recurring pattern. Namun perbaikan tidak muncul dari daftar rekomendasi. Perbaikan hanya muncul ketika tim mengakui masalah, memilih perubahan, mengambil owner, dan menuntaskannya hingga sprint berikutnya.

Jika temuan-temuan ini disandingkan, muncul pola umum: AI hampir di semua tempat membuat input ke rapat menjadi lebih kaya. Dan hampir di semua tempat menciptakan godaan untuk mengacaukan input yang kaya dengan keputusan yang sudah diambil.

Peta perubahan per Scrum event

Rapat / praktik Apa yang AI permurah Apa yang tetap ada pada manusia Risiko utama
Backlog Refinement Pengumpulan konteks, draf rumusan, kriteria penerimaan, kasus batas, pertanyaan terbuka. Pemeriksaan makna, aturan domain, batasan teknis, dan kesiapan untuk membahas tugas. Kejelasan palsu: tugas tampak siap karena ditulis dengan baik.
Sprint Planning Opsi Sprint Goal, scope, dependensi, risiko, dekomposisi, skenario tes. Keputusan tim tentang tujuan, cakupan, realisme, Definition of Done, dan komitmen untuk sprint. Realisme palsu: rencana tampak dapat dieksekusi karena tersusun dengan mulus.
Daily Scrum Sinyal awal tentang jalannya sprint, blocker, PR, tes, keputusan, dan dependensi. Shared awareness, adaptasi Sprint Backlog, dan keputusan tentang apa yang berubah dalam pekerjaan terdekat. Status bot: rapat berubah menjadi laporan tentang orang, bukan percakapan tentang Sprint Goal.
Sprint Review Release notes, gambaran hasil, metrik produk, umpan balik, dan pertanyaan terbuka. Inspeksi inkremen yang jujur, percakapan dengan stakeholder, dan adaptasi Product Backlog. Demo teater: ditampilkan dengan indah, tetapi keputusan produk tidak diambil.
Sprint Retrospective Fakta tentang proses, recurring pattern, action item lama, evidence untuk percakapan. Rasa aman psikologis, pengakuan masalah, pemilihan perbaikan, dan follow-through. Daftar rekomendasi AI alih-alih perubahan perilaku tim.

Tabel ini tidak mengatakan bahwa AI “meningkatkan Scrum”. Itu akan menjadi klaim yang terlalu kuat. Basis bukti independen langsung khusus untuk AI-assisted Scrum events masih sedikit, dan dalam beberapa research brief seri ini saya secara khusus mencatat celah tersebut. Rumusan yang lebih cermat berbeda: AI dapat memperkuat praktik inspeksi dan adaptasi yang matang, tetapi sama mudahnya memperkuat anti-pattern lama jika anti-pattern itu sudah hidup di tim.

Ini selaras dengan kerangka hati-hati DORA State of AI-assisted Software Development 2025: AI sebaiknya dipandang bukan sebagai jaminan mandiri untuk delivery yang lebih baik, melainkan sebagai penguat sistem organisasi yang sudah ada. Jika tim mampu membahas nilai, risiko, kualitas, dan proses, AI membuat input lebih kaya. Jika tim terbiasa menggantikan inspeksi dengan status, AI akan membuat status lebih cepat dan lebih indah.

Studi kasus menyeluruh: B2B LMS dan email reminder

Di semua artikel seri ini saya mempertahankan satu contoh: platform B2B LMS, di mana klien besar menetapkan kursus wajib kepada karyawan, dan tim menambahkan email reminder bagi mereka yang belum menyelesaikan kursus wajib sebelum tenggat. Kasus ini dengan baik menunjukkan bahwa AI mengubah bukan satu rapat tertentu, melainkan seluruh rantai perhatian tim.

Pada refinement AI membantu mengumpulkan konteks klien, permintaan serupa, status penugasan, arsitektur notifikasi, pertanyaan tentang zona waktu, deduplikasi, pengaturan bahasa, dan log riwayat. Tim lebih cepat sampai pada backlog item yang bermakna. Namun tim tetap harus memutuskan apa yang dianggap kursus belum selesai, bagaimana menangani expired, di mana batas versi pertama, dan data apa yang tidak boleh diberikan kepada model.

Pada planning AI membantu menyusun beberapa opsi Sprint Goal dan cakupan pekerjaan: minimal, diperluas, ambisius, di luar cakupan. Tim lebih cepat melihat kompromi. Namun tim tetap harus menjawab dengan jujur apa yang benar-benar muat dalam sprint, apa yang mendukung Sprint Goal, apa yang bisa dihapus lebih dulu, dan di mana risiko terhadap Definition of Done tersembunyi.

Pada Daily Scrum AI mengangkat sinyal: PR untuk scheduler terbuka tanpa review, QA menunggu data tes, di chat dibahas risiko duplikasi, muncul ketidakpastian tentang zona waktu, support membawa pertanyaan klien baru. Ini input yang baik. Namun tim sendiri yang memutuskan siapa yang perlu disinkronkan setelah Daily, risiko mana yang perlu dieskalasi, dan bagaimana menyesuaikan rencana terdekat.

Pada Sprint Review, AI mengumpulkan hasil dan umpan balik: siapa yang menerima pengingat, berapa open/click rates, tiket apa yang masuk ke dukungan, apa yang dikatakan klien pilot, backlog item mana yang terkait dengan Sprint Goal ini. Namun nilai produk baru muncul ketika Scrum Team dan stakeholder memutuskan apa yang harus dilakukan selanjutnya: memperjelas eligibility, mengubah backlog, menambahkan diagnostik untuk dukungan, atau meninjau ulang prioritas expired.

Pada Sprint Retrospective, AI membantu melihat bahwa tim kembali terlambat mendapatkan data pengujian, bahwa review terhenti di tempat-tempat yang serupa, bahwa Definition of Done secara implisit berbeda antar peran, dan action item dari sprint sebelumnya tidak dijalankan. Namun perbaikan baru dimulai ketika tim memilih satu eksperimen konkret untuk sprint berikutnya: misalnya, menetapkan owner data pengujian di awal, mengurangi ukuran PR, atau memperjelas DoD untuk tugas dengan pengiriman email.

Kasus yang sama menunjukkan hal utama: AI dapat menarik benang fakta melalui seluruh sprint. Namun ia tidak dapat menggantikan keputusan yang membuat fakta-fakta itu berguna.

Lima anti-pattern yang dipercepat AI

Hal paling tidak menyenangkan tentang AI bukanlah bahwa ia kadang salah. Kesalahan bisa ditangkap. Hal paling tidak menyenangkan adalah bahwa ia mampu membuat proses buruk sangat meyakinkan.

Kejelasan palsu. Dalam refinement, tim melihat user story yang rapi, acceptance criteria yang terperinci, dan daftar edge case. Tampaknya tugasnya sudah jelas. Namun jika fakta tidak dapat ditelusuri ke sumbernya, dan pertanyaan terbuka disembunyikan di bawah teks yang mulus, tim hanya lebih cepat menciptakan ilusi kesiapan.

Realistis palsu. Dalam planning, model menyusun Sprint Plan yang indah: tujuan, scope, dependensi, risks, steps, estimates. Namun jika Pengembang tidak memeriksa capacity, DoD, pekerjaan yang belum selesai, dan batasan nyata, itu bukan rencana. Itu harapan yang diformat dengan baik.

Status-bot. Dalam Daily Scrum, AI setiap hari menulis siapa melakukan apa, apa yang berubah di Jira, dan PR mana yang terbuka. Itu nyaman. Namun jika tim berhenti membicarakan Sprint Goal dan adaptasi terdekat dari rencana, Daily Scrum menjadi pelaporan.

Teater demo. Dalam Sprint Review, AI menyiapkan slide, release notes, dan ringkasan umpan balik. Semuanya tampak profesional. Namun jika stakeholder tidak berdebat, Product Backlog tidak berubah, dan sinyal-sinyal yang tidak nyaman dirata-ratakan, tim hanya melakukan presentasi, bukan Review.

Retro tanpa perubahan. Dalam Retrospective, AI menawarkan root causes dan action items. Namun jika orang tidak siap berbicara jujur, jika tidak ada owner, pemeriksaan efek, dan tempat di Sprint Backlog berikutnya, itu bukan improvement. Itu protokol perbaikan tanpa perbaikan.

Kelima anti-pattern memiliki satu sifat dasar: AI menurunkan biaya bentuk, tetapi bentuk mulai berpura-pura menjadi isi. Itulah sebabnya dalam artikel-artikel seri ini begitu sering diulang sumber tentang overreliance, confabulation, misinformation, information integrity, privacy, dan human oversight: NIST AI Risk Management Framework 1.0, NIST Generative AI Profile dan OWASP Top 10 for LLM Applications 2025 dengan baik menggambarkan kelas-kelas risiko ini pada tingkat sistem AI. Dalam Scrum Team, hal-hal itu terwujud sangat konkret: sebagai kepercayaan yang terlalu kuat pada draf yang indah.

Apa yang harus menjadi lebih kuat dalam tim

Jika AI mempercepat persiapan, tim bisa keliru menyimpulkan bahwa mereka membutuhkan lebih sedikit disiplin. Dalam praktiknya sebaliknya. Semakin cepat draf dibuat, semakin penting disiplin pemeriksaan.

Saya akan menyoroti lima keterampilan tim yang menjadi lebih penting, bukan kurang penting.

Pertama: memisahkan fakta dari asumsi. Dalam setiap input AI harus terlihat apa yang berasal dari sumber, apa yang merupakan interpretasi model, dan apa yang merupakan hipotesis kerja. Ini sangat penting dalam refinement, planning, dan Review, di mana kesalahan mudah berubah menjadi backlog item atau keputusan produk.

Kedua: memeriksa bukan hanya kelengkapan, tetapi juga kemulusan yang tampak masuk akal. Reviewer yang baik atas draf AI bertanya bukan “apa lagi yang perlu ditambahkan?”, melainkan “apa yang di sini mungkin tidak benar?”, “dependensi apa yang mungkin hilang dari ringkasan?”, “sinyal tidak nyaman apa yang dirata-ratakan oleh model?”.

Ketiga: tidak menggunakan sinyal AI sebagai penilaian orang. Daily Scrum dan Retrospective sangat sensitif terhadap batas ini. Jika model membaca Jira, Git, PR comments, dan chat, sangat mudah beralih dari analisis pekerjaan ke monitoring tersembunyi. Ini merusak kepercayaan dan membuat percakapan lebih hati-hati. Secara praktis ini berarti: menganalisis work and system, not people.

Keempat: menetapkan pemilik pemeriksaan. Makna bisnis diperiksa oleh Product Owner. Keterhubungan persyaratan — analis. Batasan arsitektur — pengembang. Testability dan failure modes — QA. Batas UX — desainer. Kualitas pertemuan dan kesepakatan tim — Scrum Master. AI dapat menyiapkan draf umum, tetapi tidak dapat menjadi pemilik pemeriksaan.

Kelima: membawa keputusan hingga perubahan pekerjaan. Jika hasil Sprint Review tidak mengubah Product Backlog, dan hasil Sprint Retrospective tidak memunculkan next-sprint experiment yang dapat diuji, AI mungkin membantu dengan dokumen, tetapi belum tentu membantu dengan Scrum.

Ke mana waktu yang terbebaskan harus dialokasikan

Salah satu pertanyaan terpenting dalam seri ini sebenarnya bukan pertanyaan teknis. Jika AI menghemat waktu tim dalam persiapan, ke mana waktu itu pergi?

Jawaban buruk: langsung isi dengan lebih banyak tugas. Maka AI hanya meningkatkan kepadatan alur dan menyamarkan kelebihan beban. Tim lebih cepat menyiapkan tugas, lebih cepat menyusun rencana, lebih cepat menulis status, dan lebih cepat menerbitkan protokol, tetapi tidak menjadi lebih cermat terhadap kualitas keputusan.

Jawaban yang lebih matang: sebagian waktu yang terbebaskan diinvestasikan ke hal-hal yang sebelumnya selalu kalah oleh urgensi. Periksa konteks klien yang diperdebatkan. Perjelas Definition of Done. Lengkapi data uji. Bedah masalah review yang berulang. Perbaiki dokumentasi. Kurangi technical debt. Tidur cukup sebelum planning yang sulit, kalau jujur.

AI berguna bukan ketika tim sekadar melakukan lebih banyak. Ia berguna ketika tim mulai menghabiskan lebih sedikit perhatian untuk menceritakan ulang hal yang sudah jelas dan lebih banyak perhatian untuk keputusan yang sebelumnya ditunda karena kebisingan.

Cara praktis menerapkan AI dalam Scrum events

Jika tim bertanya kepada saya harus mulai dari mana, saya tidak akan memulai dari “AI-transformation of Scrum” yang besar. Saya akan memulai dari peta kecil persiapan untuk events.

Sebelum menerapkan AI di setiap pertemuan, ada tujuh pertanyaan yang perlu dijawab:

  • input apa yang benar-benar membantu inspeksi dan adaptasi dalam pertemuan ini;
  • sumber mana yang boleh digunakan, dan mana yang tidak;
  • bagaimana fakta, hipotesis, dan interpretasi model dipisahkan;
  • siapa yang memverifikasi bisnis, arsitektur, pengujian, UX, data, dan risiko;
  • anti-pattern pertemuan ini apa yang bisa diperkuat AI;
  • apa yang akan dianggap sebagai human override atas rekomendasi AI;
  • bagaimana tim akan tahu bahwa event menjadi lebih berguna, bukan sekadar lebih singkat.

Pertanyaan terakhir sangat penting. Memendeknya durasi pertemuan saja tidak membuktikan perbaikan. Daily Scrum bisa menjadi lebih singkat dan lebih buruk jika tim berhenti mengadaptasi rencana. Sprint Review bisa menjadi lebih indah dan lebih lemah jika umpan balik hilang. Retrospective bisa menjadi lebih rapi dan lebih tidak berguna jika action items tidak ada yang menjalankan.

Karena itu saya tidak akan melihat “berapa menit yang dihemat”, tetapi tanda-tanda yang lebih hidup: tim lebih awal melihat risiko, lebih sedikit berdebat tentang fakta, lebih baik memisahkan hal yang belum diketahui, lebih sering mengubah Product Backlog setelah Review, lebih jujur mengadaptasi Sprint Backlog di dalam sprint, memilih improvement experiments yang lebih sedikit tetapi lebih konkret setelah Retrospective.

Jadi apa yang sebenarnya berubah

AI mengubah pertemuan klasik Scrum sebagai penguat lapisan persiapan dan analitis. Ia lebih cepat mengumpulkan materi untuk refinement, opsi rencana untuk planning, sinyal untuk Daily Scrum, hasil dan umpan balik untuk Sprint Review, fakta dan pola untuk Retrospective.

Tetapi ia tidak mengubah prinsip utama: Scrum events ada bukan untuk memproduksi dokumen, status, demo, dan protokol. Mereka ada untuk inspeksi dan adaptasi. Jika AI membantu tim melihat realitas dengan lebih baik dan lebih cepat beralih ke keputusan yang sadar, ia berguna. Jika AI membuat ritual lama lebih mulus, tim tidak mendapatkan perbaikan Scrum, melainkan versi dipercepat dari masalah lama.

Karena itu kesimpulan akhir saya begini: menerapkan AI dalam Scrum events sebaiknya bukan sebagai pengganti pertemuan, melainkan sebagai lapisan persiapan di bawah inspeksi manusia. Biarkan AI mengumpulkan fakta, mengusulkan opsi, menyoroti risiko, mengingatkan keputusan, dan membantu mencatat follow-up. Tetapi tim harus mempertahankan hal yang menjadi alasan Scrum ada: transparansi, pemeriksaan, adaptasi, tanggung jawab, dan kemampuan untuk mengubah pekerjaan selanjutnya secara jujur.

Tim yang matang tidak bertanya: “pertemuan mana yang sekarang bisa kita hapus?”. Ia bertanya dengan cara lain: “bagian kebisingan mana yang bisa diambil AI, agar kita punya lebih banyak perhatian untuk makna, nilai, kualitas, dan perubahan perilaku?”. Ini pertanyaan yang kurang menarik. Tetapi jauh lebih dekat ke pekerjaan nyata tim pengembangan lintas fungsi.

Sumber dan acuan

← Semua esai