Sprint Review: Cara Menjalankannya (Agenda dan Contoh)

Sprint review adalah momen di mana tim menunjukkan apa yang sebenarnya telah mereka bangun. Jika dijalankan dengan baik, ini adalah salah satu jam paling berharga dalam sebuah sprint: percakapan nyata antara orang-orang yang membangun produk dan orang-orang yang menggunakan atau mendanainya.

Apa Itu Sprint Review?

Sprint review adalah event Scrum formal yang diadakan di akhir setiap sprint. Tim memeriksa increment (semua yang diselesaikan selama sprint) dan berkolaborasi dengan stakeholder untuk menyesuaikan product backlog berdasarkan apa yang mereka pelajari.

Scrum Guide (Schwaber dan Sutherland, 2020) mendefinisikannya sebagai "sesi kerja" alih-alih laporan status atau demo satu arah. Perbedaan ini penting. Stakeholder bukan penonton; mereka adalah peserta yang membantu tim memutuskan apa yang harus dibangun selanjutnya.

Sprint review dibatasi waktu maksimum empat jam untuk sprint satu bulan. Sprint yang lebih pendek mendapat review yang proporsional lebih singkat; sebagian besar tim dengan sprint dua mingguan membatasinya menjadi satu atau dua jam.

Fakta Penting

• Scrum Guide (2020) menetapkan timebox empat jam untuk sprint satu bulan, diskalakan turun untuk sprint yang lebih pendek.
• Sprint review adalah satu dari lima event Scrum: sprint planning, daily scrum, sprint review, sprint retrospective, dan sprint itu sendiri.
• Laporan State of Agile 2023 (Digital.ai) menemukan bahwa 71% responden menggunakan Scrum atau hybrid Scrum, menjadikan sprint review salah satu rapat feedback terstruktur yang paling banyak dipraktikkan dalam software.

Kerangka yang berguna: sprint review menjawab "Apakah kami membangun hal yang tepat?" Sprint retrospective menjawab "Apakah kami membangunnya dengan cara yang tepat?"

Sprint Review vs Sprint Retrospective

Kedua event ini berlangsung berurutan di akhir setiap sprint, sehingga tim sering mencampuradukkannya. Padahal keduanya adalah percakapan yang secara fundamental berbeda.

Untuk rincian lengkap format dan pertanyaan retrospective, lihat panduan sprint retrospective.

Siapa yang Hadir di Sprint Review?

Scrum Guide mencantumkan peserta berikut:

• Tim Scrum: developer yang membangun increment, Product Owner, dan Scrum Master
• Stakeholder: siapa pun yang diundang Product Owner, seperti pelanggan, pengguna, eksekutif, atau sponsor bisnis
• Ahli materi (subject matter expert): secara opsional, spesialis yang masukannya relevan untuk keputusan tentang apa yang akan dibangun selanjutnya

Product Owner biasanya mengundang para stakeholder. Scrum Master memastikan event tersebut tetap produktif dan sesuai timebox. Developer mempresentasikan increment dan menjawab pertanyaan secara langsung. Keterusterangan ini disengaja. Stakeholder mendapatkan informasi tanpa filter; developer mendapatkan reaksi tanpa filter.

Agenda Sprint Review

Sprint review yang terstruktur dengan baik melewati lima bagian. Berikut contoh agenda untuk review 90 menit (khas untuk sprint dua mingguan):

Bagian 1: Pembukaan (10 menit)

Product Owner membuka dengan merekap sprint goal dan mendaftar item yang direncanakan untuk sprint tersebut. Jangan lewatkan ini. Stakeholder yang tidak hadir di sprint planning membutuhkan konteks sebelum melihat demo.

Bagian 2: Demo Increment (40 menit)

Developer mendemonstrasikan software yang berfungsi. Software yang sungguhan, bukan slide. Demo harus terhubung langsung dengan sprint goal dan menunjukkan acceptance criteria yang telah terpenuhi. Setiap fitur sebaiknya didemokan dalam skenario yang realistis, bukan walkthrough yang dipoles.

Tip: tugaskan setiap developer untuk mempresentasikan fitur yang mereka bangun. Mereka menjelaskan konteks dan memaparkan fungsionalitasnya. Ini lebih kredibel daripada satu orang yang mendemokan semuanya.

Bagian 3: Feedback Stakeholder (20 menit)

Ini adalah inti dari sprint review. Product Owner memfasilitasi percakapan terbuka. Pertanyaan untuk memancing feedback yang berguna:

• Apakah ini menyelesaikan masalah yang Anda bayangkan?
• Apa yang akan membuat ini lebih berguna?
• Apa yang harus kami fokuskan selanjutnya?
• Apakah ada yang kurang atau salah?

Dokumentasikan semuanya. Masukan stakeholder secara langsung membentuk pembaruan backlog berikutnya.

Bagian 4: Peninjauan Backlog (15 menit)

Product Owner memaparkan product backlog yang telah diperbarui. Di sinilah pembelajaran dari sprint diterjemahkan menjadi pekerjaan di masa depan. Item baru muncul. Prioritas bergeser. Tim dan stakeholder menyelaraskan apa yang paling penting selanjutnya.

Bagian 5: Penutupan (5 menit)

Berikan pratinjau sprint goal berikutnya, konfirmasi tanggal review selanjutnya, dan ucapkan terima kasih kepada stakeholder. Singkat dan jelas.

Cara Menjalankan Sprint Review yang Efektif

Langkah 1: Siapkan lingkungan demo terlebih dahulu

Jangan menunggu sampai pagi hari saat review berlangsung. Siapkan staging environment, konfirmasi akun demo berfungsi, dan uji setiap integrasi live sehari sebelumnya. Demo yang gagal membuang waktu semua orang dan mengikis kepercayaan.

Langkah 2: Beri pengarahan kepada stakeholder sebelum rapat

Kirim bahan bacaan singkat sebelumnya: sprint goal, apa yang akan didemokan, dan konteks relevan apa pun (sebuah user workflow yang sedang Anda tingkatkan, sebuah bug yang Anda perbaiki). Stakeholder memberikan feedback yang lebih baik ketika mereka memahami titik awalnya.

Langkah 3: Tetap berpegang pada software yang berfungsi

Tunjukkan hanya yang telah selesai berdasarkan Definition of Done. Jika sesuatu baru 80% selesai, jangan didemokan. Menunjukkan pekerjaan yang belum selesai menciptakan kebingungan dan ekspektasi yang tidak selaras. Increment hanyalah yang memenuhi standar tim untuk "selesai."

Langkah 4: Undang stakeholder yang tepat

Lebih banyak tidak selalu lebih baik. Undang orang-orang yang memiliki wewenang pengambilan keputusan atau wawasan pengguna langsung. Kelompok fokus berisi lima orang yang terlibat aktif menghasilkan feedback yang lebih baik daripada audiens pasif berjumlah dua puluh orang.

Langkah 5: Tangkap feedback secara real time

Tugaskan satu orang untuk mendokumentasikan masukan stakeholder selama diskusi. Item yang dapat ditindaklanjuti langsung masuk ke backlog sebelum sesi berakhir, atau paling tidak ditandai agar Product Owner segera memprosesnya setelahnya.

Langkah 6: Akhiri dengan langkah berikutnya yang jelas

Sebelum ruangan kosong, sampaikan fokus yang kemungkinan untuk sprint berikutnya. Ini tidak harus final. Tetapi mengakhiri tanpa arah bersama adalah peluang yang terlewat. Sprint review seharusnya terasa seperti sebuah bab yang ditutup dan bab baru yang dibuka.

Praktik Terbaik Sprint Review

• Jaga demo tetap realistis. Gunakan data nyata atau skenario yang mendekati nyata. Demo yang artifisial tidak mengungkap masalah usability yang sesungguhnya.
• Batasi waktu setiap segmen demo. Jika sebuah tim memiliki lima item untuk ditunjukkan, alokasikan waktu per item. Tanpa struktur, demo berjalan terlalu lama dan feedback jadi terdesak.
• Bergiliran siapa yang presentasi. Setiap developer yang mempresentasikan pekerjaannya sendiri membangun kepercayaan diri tim dan memberi stakeholder gambaran yang lebih jelas tentang tim tersebut.
• Jangan mencampurkan topik retrospective. Isu proses adalah bagian dari retro. Jika seorang stakeholder mengangkat kekhawatiran proses tim selama review, catat dan tunda ke sesi retro.
• Catat keputusan penting. Apa yang disetujui stakeholder? Apa yang diturunkan prioritasnya? Permintaan baru apa yang muncul? Keputusan-keputusan ini butuh jejak dokumentasi.

Kesalahan Umum

Memperlakukan review sebagai demo satu arah. Jika stakeholder hanya menonton dan bertepuk tangan, Anda kehilangan nilai yang seharusnya didapat. Sprint review adalah sesi kolaboratif, bukan pertunjukan teater.

Mendemokan fitur yang belum selesai. Menunjukkan pekerjaan yang masih berjalan seolah sudah selesai mengikis kepercayaan. Jika sesuatu belum siap, katakan begitu. Lewati saja atau tunjukkan sebentar dengan catatan yang jelas.

Melewatkan diskusi backlog. Tim yang mendemokan lalu langsung selesai melewatkan bagian paling penting: apa yang berubah karena apa yang baru saja mereka pelajari. Diskusi backlog adalah tempat output sprint berubah menjadi input sprint berikutnya.

Menjalankannya tanpa stakeholder yang tepat. Sprint review yang hanya diisi anggota tim internal hanyalah sinkronisasi tim biasa. Nilainya datang dari perspektif eksternal dan feedback pengguna yang nyata.

Tanpa persiapan. Demo yang dadakan sering gagal atau melebihi waktu. Sebuah checklist persiapan singkat, ditinjau sehari sebelumnya, mencegah sebagian besar bencana sprint review.

Pertanyaan yang Sering Diajukan

Apa itu sprint review?

Sprint review adalah event Scrum yang diadakan di akhir setiap sprint di mana tim mendemonstrasikan increment yang telah selesai kepada stakeholder dan mengumpulkan feedback untuk memperbarui product backlog. Ini adalah sesi kerja kolaboratif, bukan presentasi formal atau laporan status.

Berapa lama sprint review sebaiknya berlangsung?

Scrum Guide merekomendasikan maksimum empat jam untuk sprint satu bulan. Untuk sprint dua mingguan, sebagian besar tim menjalankan review dalam satu sampai dua jam. Timebox-nya diskalakan sesuai panjang sprint: sprint lebih pendek, review lebih singkat.

Apa perbedaan antara sprint review dan sprint retrospective?

Sprint review berfokus pada produk: tim menunjukkan apa yang mereka bangun dan stakeholder memberikan feedback. Sprint retrospective berfokus pada proses tim: bagaimana mereka bekerja sama dan apa yang perlu diperbaiki. Keduanya terjadi di akhir sprint, tetapi memiliki tujuan yang berbeda dan peserta yang berbeda.

Siapa yang menjalankan sprint review?

Product Owner biasanya memfasilitasi sprint review, membuka sesi, dan memimpin diskusi backlog. Scrum Master memastikan event tersebut tetap sesuai timebox dan produktif. Developer mempresentasikan increment secara langsung.

Apa yang terjadi jika sprint goal tidak tercapai?

Tim mendemokan apa yang telah selesai. Item yang belum selesai tidak dipresentasikan seolah sudah selesai. Kesenjangan antara apa yang direncanakan dan apa yang benar-benar dikirim menjadi input baik untuk pembaruan backlog maupun retrospective. Transparansi di sini jauh lebih berharga daripada mencoba memoles hasilnya.

---

Sprint review adalah salah satu event Scrum paling sederhana untuk dijalankan dan salah satu yang paling mudah dijalankan dengan buruk. Demo yang singkat dan dipersiapkan dengan baik bersama stakeholder yang tepat di ruangan mengubah setiap sprint menjadi loop feedback yang sesungguhnya. Dan itulah yang membuat tim tetap membangun produk yang tepat, bukan sekadar membangun dengan cepat.

Untuk event Scrum lainnya, mulai dengan seremoni agile dan daily standup.