Backlog Refinement dan AI: apa yang sebenarnya berubah

Pembahasan praktis tentang bagaimana AI mengubah Backlog Refinement: apa yang dipercepat, di mana risiko muncul, bagaimana waktu tim dialokasikan ulang, dan apa yang perlu diperiksa secara manual.

26 Mar 2026 · 06:54 UTC22 menit baca

Telegram Asli

Ini adalah artikel pertama dari seri tentang bagaimana AI mengubah pertemuan klasik tim pengembangan lintas fungsi. Di bawah ini saya akan mulai dengan Backlog Refinement, dan pada materi berikutnya saya akan membahas secara terpisah Planning, Daily, Review, Retrospective, lalu merangkum semuanya dalam artikel tinjauan akhir.

Saya perjelas dulu kerangkanya: di bawah ini saya membahas refinement sebagai sesi tim reguler dan praktik penajaman backlog items, bukan harus sebagai event Scrum resmi tersendiri. Ini penting untuk ketepatan istilah: dalam Scrum Guide 2020 (RU PDF) refinement dijelaskan sebagai ongoing activity, bukan sebagai event mandiri. Dalam versi bahasa Rusia Scrum Guide 2020 gagasan ini dirumuskan secara langsung: penajaman Product Backlog adalah aktivitas berkelanjutan untuk menambahkan detail, urutan, dan ukuran.

Backlog Refinement adalah salah satu tempat pertama di mana AI mulai memberikan manfaat yang cukup nyata bagi tim. AI membantu lebih cepat mengumpulkan konteks, menyiapkan draf rumusan, dengan cepat menghasilkan draf kriteria penerimaan, menemukan kasus serupa, dan merumuskan daftar pertanyaan terbuka. Tesis ini juga didukung oleh karya yang lebih terapan: misalnya, dalam LLM-Assisted Requirements Engineering in Agile MDD secara khusus memvalidasi generasi acceptance criteria, dan dalam studi kasus industri Acceptance Test Generation with Large Language Models pengguna mencatat bahwa skenario AI membantu memperhatikan kasus yang sebelumnya terlewat. Namun justru karena itu, di sini sangat mudah terjebak: mengacaukan draf yang tertata rapi dengan tugas yang benar-benar dipahami.

Menurut saya, AI tidak menyederhanakan refinement dalam arti bahwa tim sekarang perlu berpikir lebih sedikit. AI lebih tepatnya membuat lebih murah pekerjaan manual termahal di sekitarnya — pencarian, ringkasan, pengemasan, dan dekomposisi awal. Artinya, nilai diskusi tim itu sendiri tidak hilang, melainkan bergeser: lebih sedikit waktu dihabiskan untuk merangkai sesuatu yang mirip tugas dari kekacauan, dan lebih banyak untuk memahami apakah hal itu memang bisa diambil untuk dikerjakan.

“AI mempercepat bukan kesepakatan tim itu sendiri, melainkan persiapan materi untuknya”

Mengapa perubahan paling terasa justru pada Backlog Refinement

Jika melihat ritual dan pertemuan tim yang biasa dalam praktik Agile, refinement menjadi salah satu yang paling sensitif terhadap kehadiran AI. Alasannya cukup sederhana: seputar refinement secara historis ada banyak rutinitas intelektual manual. Perlu mengumpulkan konteks yang tersebar dari dokumen, tiket lama, percakapan, dan ingatan orang. Perlu mengubah ide bisnis mentah menjadi backlog item yang jelas. Perlu merumuskan masalah bisnis, skenario, kriteria penerimaan, batasan, pertanyaan terbuka, dependensi, dan kemungkinan kasus batas.

Justru pada lapisan inilah AI masuk dengan sangat baik. Ini juga sejalan dengan bagaimana penerapan LLM dalam requirements engineering dibahas saat ini: model kuat dalam peringkasan, penstrukturan awal kebutuhan, pembuatan draf, dan dukungan persiapan analitis, tetapi lebih lemah di tempat yang membutuhkan ketepatan domain, ketertelusuran, dan tanggung jawab atas keputusan akhir. Dalam pengertian ini, refinement memang menjadi salah satu proses pertama di mana manfaat AI terasa cepat, dan batas keandalannya — hampir seketika. Hal ini dibahas dengan baik dalam tinjauan Challenges in applying large language models to requirements engineering tasks, dalam tinjauan sistematis terbaru Large Language Models (LLMs) for Requirements Engineering (RE): A Systematic Literature Review, dan dalam karya yang lebih terapan LLM-Assisted Requirements Engineering in Agile MDD.

Tim menganalisis backlog item dengan bantuan AI dan artefak Agile — AI sangat mempercepat persiapan untuk refinement, tetapi tidak menggantikan verifikasi makna secara kolektif.

Bagaimana refinement tampak sebelum AI

Jika disederhanakan, sebelum AI refinement sangat sering merupakan proses perakitan pemahaman secara manual. Yang masuk ke backlog bukan tugas yang sudah jadi, melainkan lebih berupa niat bisnis: memperbaiki onboarding, menambahkan pengingat, memberi manajer laporan baru, mengurangi jumlah tiket yang terlambat. Setelah itu Product Owner, analis, atau salah satu lead mulai mengumpulkan konteks secara manual: mengangkat keluhan pelanggan lama, fitur serupa, batasan arsitektur saat ini, status yang berlaku, notifikasi yang ada, pola UI, dan segala hal lain yang bisa tiba-tiba muncul dalam diskusi.

Selanjutnya orang yang sama atau beberapa orang secara manual mencoba mengubah hasil yang dikumpulkan menjadi draf pertama: merumuskan masalah bisnis, mendeskripsikan skenario, menulis kriteria penerimaan, mengangkat pertanyaan terbuka, dan menandai kemungkinan batasan. Namun bahkan jika draf seperti itu sudah ada, rapat tetap sering habis untuk mengangkat konteks ke kepala seluruh tim. Product owner menjelaskan ulang apa yang diinginkan bisnis, analis menceritakan apa yang sudah berhasil diketahui, developer mengangkat batasan arsitektur, QA mengeluarkan skenario batas, desainer dan frontend membahas apakah perlu layar terpisah dan di mana layar itu akan berada.

Kasus yang sama: tanpa AI dan dengan AI

Agar tidak berhenti pada rumus umum, saya akan mengambil kasus konkret. Produknya adalah platform LMS B2B untuk pelatihan korporat. Klien besar menugaskan karyawan untuk mengikuti kursus wajib tentang compliance, keamanan, dan regulasi internal. Dari pihak bisnis datang permintaan: perlu menambahkan pengingat email otomatis kepada karyawan yang belum menyelesaikan kursus wajib sebelum tenggat waktu.

Sekilas ini terlihat seperti tugas sederhana tentang pengiriman email. Namun sejak langkah pertama sudah jelas bahwa sebenarnya di sini ada banyak percabangan: siapa yang dianggap belum menyelesaikan kursus, kapan pengingat dikirim, bagaimana menghindari duplikasi pengiriman, bagaimana ini dikonfigurasi oleh klien, apakah perlu log pengiriman, apa yang harus dilakukan dengan time zone, bahasa email apa yang dipakai, dan apakah perlu mengecualikan pengguna archived dan yang dinonaktifkan.

Dalam mode tanpa AI, tim sampai pada pertanyaan-pertanyaan ini terutama melalui persiapan manual yang panjang dan percakapan besar dalam rapat itu sendiri. Pertama, Product owner mengangkat konteks klien. Lalu analis secara manual menelusuri materi internal: mencari permintaan lama yang serupa, melihat layanan notifikasi, memeriksa status assignment saat ini, keberadaan tugas penjadwal, field pengaturan bahasa dan zona waktu. Bahkan pada tahap ini batasan nyata sudah muncul: di sistem ada template email, tetapi hanya untuk email transaksional; zona waktu disimpan di tingkat klien, bukan pengguna; tidak ada log pengiriman; model pengingat tersendiri di produk juga tidak ada.

Setelah itu analis secara manual menyusun draf pertama spesifikasi, tetapi draf itu tetap belum matang. Misalnya, di dalamnya mungkin belum tercatat status persis yang harus dikirimi pengingat, logika deduplikasi, cakupan kerja minimum untuk UI, fallback bahasa, atau batas versi pertama. Dan pada refinement itu sendiri tim melengkapi tugas langsung selama percakapan. Di sanalah terungkap bahwa pengingat hanya diperlukan untuk kursus wajib, bahwa status not_started dan in_progress cocok, sedangkan expired sebaiknya tidak diambil untuk versi pertama, bahwa tanpa jurnal pengiriman, dukungan dan tim pendamping klien akan cepat tenggelam dalam pertanyaan, dan tanpa perlindungan terpisah akan ada duplikat saat tugas penjadwal dijalankan ulang.

Dalam mode dengan AI, kasus yang sama terlihat berbeda. Product owner mengunggah ke AI ringkasan singkat dari tim pendamping klien, permintaan klien terbaru, dan permintaan mentah awal. AI dengan cepat mengelompokkan pain point klien, menyoroti ekspektasi yang berulang, dan membantu merumuskan pernyataan masalah. Analis meminta AI mengangkat semua yang terkait dengan alur notifikasi, status penugasan, tugas penjadwal, pengaturan bahasa, zona waktu, dan tugas serupa di Jira. Backend terlebih dahulu menjalankan melalui AI deskripsi arsitektur notifikasi saat ini dan meminta usulan pendekatan teknis. Frontend dan desainer dengan cepat memeriksa di mana lebih logis untuk menempatkan pengaturan dan riwayat pengiriman. QA mengangkat daftar awal kasus batas dan risiko waktu.

Di sini biasanya muncul pertanyaan wajar: bagaimana jika AI melewatkan sesuatu? Seberapa jauh ringkasan singkat seperti itu bisa dipercaya, terutama ketika basis sumbernya besar? Penelitian dan kasus praktis di sini memberikan gambaran yang cukup bijak: LLM memang dapat mempercepat pembuatan user story, draf kriteria penerimaan, dan spesifikasi awal, tetapi kualitas hasilnya sangat bergantung pada konteks masukan, domain, dan pemeriksaan manusia setelahnya. Karena itu berguna untuk mengingat juga karya yang lebih terapan seperti AI-Generated User Stories: Are They Good Enough? dan LLM-Assisted Requirements Engineering in Agile MDD: keduanya dengan baik menunjukkan bahwa menghasilkan draf yang kuat dan kesiapan untuk pengembangan bukanlah hal yang sama.

Berdasarkan pengalaman saya bekerja dengan Cursor, dalam skenario terapan saya cukup jarang meragukan apakah model mampu menyusun draf pertama yang diperlukan dari kumpulan sumber yang besar. Yang jauh lebih penting adalah hal lain: seberapa baik saya merumuskan tugas, batasan apa yang saya tetapkan, pertanyaan klarifikasi apa yang sempat saya tambahkan, dan bagaimana tepatnya saya mengorganisasi pemeriksaan hasil. Ketika keraguan muncul, saya tidak mencoba menyelesaikannya dengan pertanyaan "percaya atau tidak percaya pada AI" — saya cukup memperjelas permintaan, meminta sumber ditunjukkan secara terpisah, mengeluarkan bagian yang diperdebatkan, memisahkan fakta dan asumsi, atau menyusun ulang jawaban dengan kerangka lain. Dalam pengertian ini, bekerja dengan AI sangat mirip dengan coaching: keterampilan mengajukan pertanyaan yang tepat itu bermanfaat, pertanyaan yang tidak sekadar memicu generasi, tetapi mengarahkan penalaran model ke arah yang diinginkan.

Ini tentu saja pengalaman pribadi saya, bukan aturan universal. Mungkin saya akan menulis secara terpisah satu materi lagi khusus tentang kepercayaan pada AI, kualitas pertanyaan klarifikasi, dan pemeriksaan hasil yang terkendali. Untuk refinement hal ini sangat penting: semakin besar basis sumber dan semakin meyakinkan ringkasan singkatnya, semakin tinggi risiko mencampuradukkan persiapan yang kuat dengan pemahaman yang sudah terverifikasi.

“Semakin besar basis sumber dan semakin meyakinkan ringkasan singkatnya, semakin tinggi risiko mencampuradukkan persiapan yang kuat dengan pemahaman yang sudah terverifikasi”

Hasilnya, tim datang ke refinement bukan lagi dengan ide mentah, melainkan dengan persiapan yang cukup kuat: ada draf user story, draf kriteria penerimaan, pertanyaan terbuka, daftar risiko, pendekatan teknis awal, dan usulan UI. Karena itu, pertemuan itu sendiri menjadi lebih singkat dan lebih substantif. Tim tidak lagi menghabiskan begitu banyak waktu untuk membangun konteks dasar dan terutama membahas hal-hal yang diperdebatkan: apakah akan menyertakan expired, apakah akan membuat zona waktu terpisah per pengguna, apakah perlu log pengiriman di rilis pertama, apakah cukup dengan pemicu tetap, bagaimana melindungi dari duplikat, dan apa yang dianggap sebagai batas versi pertama.

Apa inti kemajuan tim?

Ketika tim baru mulai menggunakan AI, AI terutama berfungsi sebagai generator cepat untuk draf pertama. Namun seiring kematangan, langkah logis berikutnya adalah berhenti hanya bekerja dengan model umum dan mulai secara bertahap memindahkan ke konteks tim yang terkendali hal-hal yang sebelumnya hanya hidup di memori orang. Ini bisa berupa prinsip produk, templat kriteria penerimaan, alasan umum sebuah tugas ditolak saat refinement, kasus batas yang tipikal, batasan arsitektur, kumpulan pertanyaan klarifikasi yang tipikal, regulasi internal organisasi, Definition of Ready dan Definition of Done di tingkat organisasi dan tim, serta contoh solusi yang baik untuk kasus serupa.

Saat itulah kualitas draf pertama benar-benar mulai meningkat. Bukan karena model tiba-tiba “memahami domainnya sendiri”, melainkan karena tim telah belajar secara sistematis menuangkan ke dalamnya pola pikir mereka sendiri, batasan internal, dan aturan pemeriksaan. Dan di sini refinement menjadi bukan hanya tempat untuk memeriksa tugas, tetapi juga tempat di mana tim secara bertahap melatih lapisan AI mereka sendiri.

Apa yang berubah per peran

Di bawah ini berguna untuk melihat bukan hanya peran sebagai fungsi abstrak, tetapi juga tindakan konkret dalam kasus yang disimulasikan dengan pengingat kursus wajib. Justru dengan begitu perbedaan antara mode tanpa AI dan dengan AI menjadi benar-benar terlihat.

Peran	Tanpa AI	Dengan AI
Product Owner	Mengangkat konteks pelanggan secara manual, merangkum permintaan dari tim dukungan pelanggan, menjelaskan ulang masalah bisnis di pertemuan.	Menyiapkan input yang dianonimkan, meminta AI mengelompokkan pain point pelanggan, membawa ke pertemuan draf rumusan masalah dan daftar keputusan produk yang diperdebatkan.
Business Analyst	Mencari kasus serupa, mengumpulkan status, batasan, dependensi secara manual, lalu menulis ulang semuanya menjadi draf pertama spesifikasi.	Menyusun permintaan ke AI berdasarkan sumber, mencocokkan ringkasan singkat dengan sumber, menyunting kriteria penerimaan, mencatat pertanyaan terbuka dan hal yang mungkin terlewat oleh model.
Backend Developer	Sering kali baru pertama kali mendalami masalah secara mendalam saat refinement, mengangkat batasan layanan notifikasi dan risiko duplikat langsung selama diskusi.	Sebelum pertemuan sudah mendapatkan draf pertama opsi teknis, memeriksa lebih awal deduplikasi, tugas penjadwal, audit trail, dan batas versi pertama.
Frontend Developer	Di pertemuan bersama desainer mencoba memahami apakah perlu layar terpisah, di mana pengaturan akan berada, dan apa yang benar-benar termasuk dalam UI minimal.	Sebelum pertemuan melihat draf AI untuk integrasi UI, menandai lebih awal bagian yang diperdebatkan terkait pengaturan, status, dan batasan antarmuka.
Quality Engineer / QA Engineer	Bergabung terutama di pertemuan, menggali skenario negatif, benturan status, dan risiko waktu langsung dalam diskusi bersama.	Sebelum pertemuan mendapatkan daftar awal kasus batas, memeriksa bahwa AI tidak melewatkan duplikat, zona waktu, skenario fallback bahasa, dan pengecualian berdasarkan status pengguna.
UX/UI Designer	Memahami tugas selama diskusi dan langsung memperkirakan apakah perlu layar baru, blok pengaturan, atau riwayat pengiriman.	Menguji dengan cepat bersama frontend beberapa varian pendekatan UI dan datang dengan proposal yang sudah matang, bukan dari nol.
Scrum Master	Mengumpulkan peserta, menjaga waktu, membantu agar tidak tersesat dalam penggalian konteks yang kacau, dan mengembalikan tim ke inti ketika diskusi melebar.	Lebih sedikit menghabiskan waktu untuk mekanika organisasi dan penyelarasan konteks dasar, lebih banyak untuk fasilitasi keputusan yang diperdebatkan, pencatatan pertanyaan terbuka, dan kontrol kualitas diskusi.

Keuntungan, risiko, dan waktu yang dibebaskan

Manfaat AI dalam refinement cukup terasa. Konteks lebih cepat terkumpul, draf tugas lebih cepat muncul, diskusi lebih mudah dimulai, dan hasil akhir lebih baik dikemas. Namun justru dalam refinement risiko AI juga muncul sangat awal. Risiko paling jelas adalah kejelasan palsu. AI mampu membuat backlog item yang rapi yang terlihat bagus secara visual dan struktural. Karena itu, tim lebih mudah menipu diri sendiri dengan perasaan bahwa tugas sudah dipahami, padahal masih ada celah produk dan teknis di dalamnya.

Di sini berguna untuk menyebut sesuatu dengan namanya. Pertama, ini adalah bias otomasi dan ketergantungan berlebihan — kecenderungan menerima rekomendasi sistem terlalu mudah dan beralih dari verifikasi aktif ke pemantauan yang lebih pasif. Dalam profil NIST untuk AI generatif ini dijelaskan secara langsung sebagai kepercayaan berlebihan terhadap sistem AI, dan dalam studi empiris Automation Bias in AI-Decision Support: Results from an Empirical Study ditunjukkan bahwa manfaat sistem yang dirasakan tinggi dapat meningkatkan persetujuan palsu terhadap kesalahannya, sedangkan kualitas pelatihan pengguna menurunkan kemungkinan efek tersebut. Kedua, ini adalah halusinasi model — kesimpulan yang masuk akal tetapi tidak didukung sumber. Untuk refinement ini sangat kritis, karena AI hampir selalu bekerja melalui peringkasan dokumen, tiket, dan percakapan, sehingga risikonya bukan hanya pada “draf kriteria penerimaan yang indah tetapi fiktif”, tetapi juga pada distorsi diam-diam terhadap konteks asli. Itulah sebabnya dalam refinement AI lebih sering salah bukan pada gaya teks, tetapi pada fakta konteks — dan risiko ini dijelaskan dengan baik dalam karya On Faithfulness and Factuality in Abstractive Summarization. Penangkal praktisnya cukup sederhana: minta model memisahkan fakta dari hipotesis, menuntut referensi ke sumber, dan menyusun ringkasan singkat sedemikian rupa sehingga dapat dengan cepat ditelusuri kembali ke dokumen, tiket, dan keputusan tim.

Ada juga lapisan risiko lain — data. Dalam kasus di atas, AI bekerja dengan permintaan klien, deskripsi sistem internal, dan sinyal pengguna. Karena itu, penting bagi tim untuk menyepakati sejak awal apa yang boleh dan tidak boleh dikirim ke model. Untuk generative AI, risiko tidak terbatas pada prompt saja: data pribadi dapat muncul di input, di output, dan bahkan melalui memorization/regurgitation model. Oleh karena itu, jika dalam pekerjaan terdapat data pribadi atau konteks klien yang sensitif, prinsip dasar higiene data harus menjadi kewajiban: meminimalkan volume data dalam prompt, menganonimkan input bila memungkinkan, tidak menarik ekspor mentah ke model tanpa penyaringan, memahami tujuan pemrosesan secara eksplisit, dan tidak menerima begitu saja klaim penyedia seperti “kami tidak memproses data pribadi” atau “model bersifat anonim” tanpa kontrol organisasi dan teknis yang dapat diverifikasi. Secara terpisah, berguna untuk menetapkan sejak awal dasar hukum pemrosesan, kumpulan bidang minimal yang diperlukan, peran dan tanggung jawab dalam proses, dan, jika berlaku, persyaratan untuk menginformasikan subjek data. Jika skenario mencakup data pribadi dan skala atau risikonya signifikan, masuk akal untuk menilai sejak awal apakah DPIA diperlukan, dan mencatat keputusan itu secara terpisah. Dalam konteks Eropa, ini sejalan dengan prinsip GDPR Article 5, dan dengan rekomendasi praktis CNIL tentang pengembangan sistem AI, serta dengan EDPS guidance on Generative AI dan EDPB Opinion 28/2024.

Dan di sini muncul pertanyaan penting lainnya: ke mana waktu yang dibebaskan dari para spesialis itu pergi. Opsi paling sederhana adalah mencoba memasukkan lebih banyak tugas ke dalamnya. Yang lebih matang adalah menginvestasikan penghematan ini ke dalam kualitas keputusan, pengurangan utang teknis, pengembangan templat internal, pelatihan, dokumentasi, dan setidaknya pengelolaan perhatian tim yang lebih baik. Dalam artikel tinjauan akhir seri ini, saya akan secara khusus membahas bahwa AI tidak hanya mengubah proses, tetapi juga budaya penggunaan waktu tim.

Biaya tersembunyi baru yang tidak boleh diabaikan

Agar pembahasan tentang efisiensi tidak terlihat terlalu mulus, penting untuk menambahkan sisi sebaliknya: AI jarang memberikan “penghematan murni” tanpa jenis pekerjaan baru. Sebagian waktu kini digunakan untuk persiapan data, pengaturan akses ke sumber, pemeliharaan prompt dan templat, verifikasi sumber, dokumentasi keputusan, dan pemeriksaan manusia. Pandangan ini sejalan dengan praktik risk management untuk generative AI: misalnya, profil NIST untuk AI generatif menekankan tidak hanya pada manfaat otomatisasi, tetapi juga pada kebutuhan akan oversight, documentation, dan kontrol manajerial.

Estimasi skenario biaya tenaga kerja untuk satu Backlog Refinement (skenario)

Di bawah ini — bukan “suhu rata-rata pasar”, melainkan model skenario untuk Backlog Refinement yang sama pada tim yang sama beranggotakan tujuh orang: PO, BA, backend, frontend, QA, designer, dan Scrum Master. Ini adalah estimasi untuk satu backlog item besar atau yang cukup tidak pasti, bukan story kecil yang sudah dipahami dengan baik. Nilai dari angka-angka ini bukan pada ketepatan hingga ke menit, melainkan pada perbandingan struktur biaya: ke mana waktu dulu pergi dan ke mana waktu pergi sekarang.

Selanjutnya yang dibahas adalah jam-orang untuk satu backlog item besar — persiapan, diskusi, dan penyempurnaan singkat setelah rapat — bukan durasi rapat itu sendiri. Rapatnya sendiri biasanya juga memendek, tetapi sebagian pekerjaan hanya berpindah ke persiapan asinkron, uji ulang klarifikasi, dan verifikasi manual yang wajib.

Catatan untuk perhitungan biaya tenaga kerja: secara historis dalam Scrum Guide 2017 (RU PDF) refinement juga dijelaskan sebagai ongoing process, dan di sana terdapat acuan bahwa biasanya memakan tidak lebih dari 10% kapasitas yang tersedia dari tim pengembangan. Dalam Scrum Guide 2020 (RU PDF) acuan tersebut sudah tidak ada, jadi tabel di bawah sebaiknya dibaca bukan sebagai norma, melainkan sebagai model skenario untuk membandingkan dua mode kerja.

Penting untuk dijelaskan secara terpisah: kolom «Dengan AI» di bawah sudah mencakup pekerjaan baru dasar yang tanpanya skenario ini tidak berjalan — persiapan data masukan, kueri klarifikasi, pemeriksaan awal ringkasan singkat, verifikasi bagian yang diperdebatkan, dan pemeriksaan manusia minimal. Jadi profit final dalam tabel bukanlah penghematan “kotor” sebelum memperhitungkan biaya baru, melainkan estimasi skenario yang lebih realistis setelah biaya tersebut dimasukkan secara dasar.

Agar estimasi ini dapat direproduksi, akan lebih mudah menghitungnya dengan skema sederhana: T_AI = T_base × ((1 − p) + p × s) + o, di mana T_base — waktu tanpa AI, p — proporsi pekerjaan yang dipercepat, s — koefisien percepatan pada bagian tersebut, dan o — pekerjaan baru untuk persiapan data, kueri klarifikasi, dan verifikasi hasil.

Di bawah ini — contoh terkalibrasi khusus untuk skenario dasar ini. Tugasnya bukan membuktikan norma universal, melainkan menunjukkan bagaimana model yang sama dapat mereproduksi angka-angka dari tabel untuk satu kasus konkret. Dalam tim nyata, parameter seperti ini sebaiknya dikalibrasi berdasarkan 3–5 Backlog Refinement terakhir dan kemudian mendapatkan rentang Anda sendiri.

# Calibrated to reproduce the table (base scenario)
# T_ai = T_base * ((1 - p) + p * s) + o
roles = {
    "PO": {"T_base": 4.5, "p": 0.75, "s": 0.20, "o": 0.7},
    "BA": {"T_base": 10.0, "p": 0.70, "s": 0.20, "o": 0.6},
    "BE": {"T_base": 3.5, "p": 0.75, "s": 0.20, "o": 0.6},
    "FE": {"T_base": 3.0, "p": 0.75, "s": 0.20, "o": 0.3},
    "QA": {"T_base": 3.0, "p": 0.50, "s": 0.20, "o": 0.2},
    "UX": {"T_base": 3.0, "p": 0.50, "s": 0.20, "o": 0.2},
    "SM": {"T_base": 2.5, "p": 0.50, "s": 0.20, "o": 0.0},
}

def t_ai(x):
    return x["T_base"] * ((1 - x["p"]) + x["p"] * x["s"]) + x["o"]

total_base = sum(r["T_base"] for r in roles.values())
total_ai = sum(t_ai(r) for r in roles.values())

print("Total base:", round(total_base, 1))
print("Total AI:", round(total_ai, 1))
print("Gain:", round(total_base - total_ai, 1))

for role, x in roles.items():
    print(role, round(t_ai(x), 1))

Peran	Tanpa AI	Dengan AI (dengan memperhitungkan pekerjaan baru)	Apa yang berubah
Product Owner	4,5 jam	2,5 jam	Lebih cepat mengumpulkan konteks pelanggan, tetapi menghabiskan sebagian waktu untuk persiapan input dan kueri klarifikasi
Business Analyst	10 jam	5 jam	Lebih sedikit pencarian manual dan penulisan ulang, lebih banyak verifikasi, penyuntingan, dan pemeriksaan bahwa AI tidak melewatkan hal penting
Backend Developer	3,5 jam	2 jam	Lebih cepat mendapatkan analisis teknis pertama, tetapi secara terpisah memeriksa batasan arsitektur dan risiko duplikasi
Frontend Developer	3 jam	1,5 jam	Lebih cepat menilai integrasi UI dan pengaturan, sekaligus lebih awal terlibat dalam pemeriksaan bagian yang diperdebatkan
Quality Engineer / QA Engineer	3 jam	2 jam	Lebih awal mendapatkan kasus batas dan risiko temporal, tetapi lebih terlibat dalam pemeriksaan kelalaian dan skenario negatif
UX/UI Designer	3 jam	2 jam	Lebih cepat mengumpulkan varian pertama pendekatan UI dan menyaring varian antarmuka yang tidak perlu lebih awal
Scrum Master	2,5 jam	1,5 jam	Lebih sedikit waktu untuk penyelarasan konteks organisasional, lebih banyak untuk fasilitasi keputusan dan pencatatan pertanyaan terbuka
Total	29,5 jam	16,5 jam	Profit skenario — sekitar 13 jam-orang pada satu Backlog Refinement seperti ini setelah memperhitungkan pekerjaan baru dasar

Rentang skenario: bagaimana profit dapat berubah

Skenario	Tanpa AI	Dengan AI	Profit bersih	Kapan ini terjadi
Hati-hati	24–28 jam	18–21 jam	4–10 jam	Sumber tidak lengkap, banyak verifikasi manual, tim baru membangun pola kerja dengan AI.
Dasar	28–32 jam	15–18 jam	10–15 jam	Kira-kira seperti inilah kasus yang dimodelkan: AI mempercepat persiapan dengan baik, tetapi pekerjaan baru untuk verifikasi sudah diperhitungkan.
Kuat	30–36 jam	14–17 jam	13–19 jam	Tim memiliki sumber yang baik, pola yang dapat diulang, dan aturan yang jelas untuk higiene data dan verifikasi manual.

Pekerjaan baru apa yang sudah diperhitungkan dalam skenario dengan AI

Tabel di bawah tidak membatalkan profit final dari tabel pertama. Tabel ini hanya menjelaskan melalui tindakan baru apa sebagian waktu yang dihemat kembali ke dalam proses — dan mengapa bahkan setelah itu efek bersihnya tetap terlihat signifikan.

Zona kerja baru	Apa yang muncul dengan AI	Mengapa ini diperlukan
Persiapan data masukan	Pembersihan, anonimisasi, ringkasan konteks yang diperlukan	Agar tidak membebani model dengan sampah dan tidak menarik data yang tidak perlu
Kueri klarifikasi	Uji ulang, klarifikasi kerangka jawaban, permintaan untuk memisahkan fakta dan asumsi	Agar tidak menganggap jawaban pertama yang indah sebagai pemahaman final
Pengaturan templat	Prompt, templat penulisan, aturan format hasil	Agar AI menghasilkan draf yang berguna dan dapat diulang, bukan teks acak
Verifikasi fakta	Pemeriksaan tautan ke sumber, istilah, status, dan batasan	Agar dapat menangkap halusinasi model dan kejelasan palsu sebelum rapat
Dokumentasi kepercayaan	Penetapan apa yang sebenarnya diperiksa secara manual dan mengapa hasilnya dapat dipercaya	Agar tim tidak mengganti tanggung jawab dengan draf yang indah

Perbedaan per tahap

Tahap	Tanpa AI	Dengan AI
Pengumpulan konteks sebelum rapat	Pencarian manual yang lama di dokumen, tiket, dan ingatan orang	Lintasan pertama atas sumber dan ringkasan singkat dibuat jauh lebih cepat
Draf rumusan	Ditulis manual dan sering tetap mentah	Ada kerangka kuat yang dapat dikritik dan diperjelas oleh tim
Backlog Refinement itu sendiri	Banyak waktu habis untuk menyelaraskan pemahaman	Fokus bergeser ke keputusan yang diperdebatkan, dependensi, dan batas versi pertama
Pengerjaan lanjutan setelah rapat	Sering kali rumusan harus ditulis ulang hampir dari awal	Hasil sudah terkemas dengan baik dan membutuhkan lebih sedikit pengerjaan manual

Daftar periksa kualitas persiapan AI untuk refinement

Penting: Definition of Ready ini adalah praktik internal tim, bukan bagian dari Scrum Guide. Di sini ia diperlukan sebagai perlindungan terhadap kejelasan palsu, kelalaian, dan tanggung jawab yang kabur dalam persiapan AI.

Definition of Ready untuk draf AI

Fakta dipisahkan dari asumsi: tim memahami apa yang diambil dari sumber dan apa yang diusulkan oleh model.

Ada tautan atau petunjuk sumber yang jelas untuk pernyataan produk dan teknis utama.

Pertanyaan terbuka tidak disembunyikan di balik teks yang rapi, melainkan dikemukakan secara eksplisit.

Istilah domain, status, batasan, peran, dan dependensi telah diperiksa.

Untuk setiap pernyataan utama, tingkat pembuktiannya jelas: ini fakta dari sumber, hipotesis kerja, atau asumsi model.

Kasus batas, skenario negatif, dan risiko temporal diperiksa secara terpisah.

Jelas data mana yang tidak boleh diberikan kepada model dan langkah higiene data apa yang diterapkan.

Ditetapkan pemilik verifikasi berdasarkan jenis pernyataan: logika bisnis, kelayakan arsitektur, keterujian, dan penanganan data.

Tim telah sepakat bahwa draf AI adalah bahan mentah untuk diskusi, bukan tugas yang hampir siap.

Agar daftar periksa ini tidak terlalu abstrak, berikut tampilannya dalam kasus kami dengan pengingat email:

AI mengusulkan untuk menyertakan status not_started, in_progress dan expired — tim secara eksplisit menandai bahwa expired masih tetap hipotesis, bukan aturan yang terkonfirmasi untuk versi pertama.
Dalam ringkasan singkat disebutkan bahwa notifikasi harus dikirim berdasarkan zona waktu pengguna — backend mencocokkannya dengan sumber dan mengonfirmasi bahwa dalam sistem saat ini zona waktu hanya disimpan di tingkat klien, sedangkan peralihan antar zona waktu dan DST perlu diperiksa secara terpisah.
AI menambahkan riwayat pengiriman sebagai bagian "jelas" dari solusi — Product Owner dan BA secara terpisah memutuskan apakah ini bagian wajib dari versi pertama atau peningkatan untuk rilis berikutnya, karena di sini juga ada pertanyaan tentang audit dan beban dukungan.
QA tidak hanya menerima daftar kasus batas, tetapi tugas konkret untuk memeriksa duplikat saat tugas penjadwal dijalankan ulang, skenario fallback bahasa, pengecualian untuk pengguna archived dan yang dinonaktifkan, serta skenario negatif seputar tenggat waktu.
Backend secara terpisah memeriksa rate limit, throttling, deliverability, dan bagaimana sistem berperilaku pada pengiriman ulang dan kesalahan penyedia.
PO dan BA juga memvalidasi kebijakan notifikasi: siapa yang boleh dikirimi pengingat, di mana diperlukan opt-out atau pengecualian klien, dan apa yang dianggap perilaku yang dapat diterima untuk kursus wajib.

Untuk kasus seperti ini, berguna juga membahas secara terpisah dua hal praktis yang sering muncul mendekati produksi: deliverability dengan cepat berubah menjadi beban bagi dukungan dan tim pendampingan klien jika tidak ada diagnostik yang baik untuk "mengapa email tidak terkirim", dan quiet hours serta jendela kalender sering kali ternyata bukan "opsi tambahan", melainkan persyaratan korporat dari klien.

Siapa memeriksa apa secara manual

Apa yang diperiksa	Siapa pemiliknya	Contoh dalam kasus LMS
Tujuan dan kebijakan produk	PO dan BA	Kepada siapa dan kapan mengirim pengingat, pengecualian apa yang diperbolehkan, di mana batas versi pertama.
Kebenaran aturan dan status	BA	Status apa yang dianggap "belum menyelesaikan", apa yang harus dilakukan dengan `expired` dan di mana ini sudah dikonfirmasi oleh sumber.
Batasan arsitektur	Pengembang backend	Deduplikasi, tugas penjadwal, idempotensi, log audit, rate limit, dan perilaku pada pengiriman ulang.
Batas UI versi pertama	Pengembang frontend dan desainer UX/UI	Di mana pengaturan berada, apakah perlu layar riwayat terpisah, dan skenario antarmuka apa yang benar-benar termasuk dalam versi pertama.
Skenario negatif dan temporal	Insinyur kualitas / QA engineer	DST, zona waktu, skenario fallback bahasa, pengecualian pengguna archived dan yang dinonaktifkan, serta duplikat saat tugas penjadwal dijalankan ulang.
Fasilitasi keputusan dan pertanyaan terbuka	Scrum Master	Apa yang sudah diputuskan, apa yang masih diperdebatkan, dan di mana tim harus mengambil kompromi yang sadar.
Higiene data dan kelayakan data	PO/BA dan, jika ada, Security atau DPO	Apa yang boleh diberikan kepada model, apa yang harus dianonimkan, dan pemeriksaan apa yang wajib sebelum menjalankan persiapan AI.

Apa yang saya rekomendasikan kepada tim

Jangan menganggap draf AI sebagai tugas yang siap hanya karena tampilannya bagus.
Secara eksplisit menyepakati bagian konteks mana yang wajib diperiksa manual oleh tim sebelum rapat, dan bagian mana yang diperiksa saat rapat itu sendiri.
Secara bertahap memindahkan pola produk dan proses milik sendiri ke lapisan AI tim, bukan hanya menggunakan obrolan umum "apa adanya".
Tidak memangkas refinement secara mekanis hanya karena persiapan menjadi lebih cepat.
Secara sadar memutuskan ke mana waktu yang terbebaskan dialokasikan: untuk kualitas, pembelajaran, dokumentasi, utang teknis, atau pemulihan perhatian tim.

Secara terpisah penting untuk mengingat batas penerapan skenario ini. Efek AI akan sangat berbeda tergantung pada kematangan dokumentasi, ketersediaan sumber internal, kompleksitas domain produk, dan sejauh mana tim mampu mengubah pengetahuan implisit menjadi konteks yang dapat diulang. Di tempat data awal lemah, AI dapat mempercepat pengemasan, tetapi belum tentu meningkatkan kualitas keputusan.

Kesimpulan

Jika sangat singkat, efek utama AI untuk refinement saya rumuskan begini: AI mempercepat bukan kesepakatan tim itu sendiri, melainkan persiapan materi untuknya. Itulah sebabnya refinement menjadi lebih cepat di awal: konteks lebih cepat dikumpulkan, draf lebih cepat muncul, pertanyaan dasar dan risiko lebih cepat teridentifikasi, hasil akhir lebih cepat dikemas.

Namun ini tidak otomatis membuat refinement lebih sederhana. Karena begitu biaya persiapan turun, nilai dari apa yang belum benar-benar dikuasai AI dengan baik justru meningkat: memahami domain, merasakan batasan nyata, mengenali kejelasan palsu, menangani data dengan hati-hati, dan membantu tim mengambil kompromi yang sadar.

Karena itu cara terbaik memandang AI dalam refinement adalah: ia menghilangkan sebagian pekerjaan manual yang mahal di sekitar praktik, tetapi membuat verifikasi makna oleh manusia menjadi lebih penting. Semakin mudah menghasilkan backlog item, semakin penting memahami mana yang benar-benar siap dibahas dan mana yang hanya terlihat bagus. Dan di artikel berikutnya dalam seri ini akan menarik untuk melihat bagaimana pergeseran ini memengaruhi bukan hanya proses, tetapi juga budaya penggunaan waktu tim.

Sumber dan acuan

← Semua esai