Templat Sprint Retrospektif untuk Tim Engineering
Mengapa kebanyakan retro tak menghasilkan perubahan
Sprint retrospektif punya masalah struktural yang tak diperbaiki templat: tim menghasilkan ide perbaikan tetapi tidak meninjaunya. Retro menghasilkan lima action item. Retro berikutnya dibuka dengan lembaran kosong. Masalah yang sama muncul lagi.
Templat di bawah ini menanamkan peninjauan ke dalam pembukaan sehingga tak bisa dilewatkan. Perubahan tunggal itu berbuat lebih banyak bagi efektivitas retro daripada penyesuaian format apa pun.
Agendanya (salin-tempel ini)
Durasi: 60 menit untuk sprint 2 minggu; 45 menit untuk sprint 1 minggu
Format: Difasilitasi, dengan board asinkron bersama (Miro, FigJam, Notion — pilihan Anda)
Bagian 1 — Tinjauan action item (10 menit)
- Baca action item sprint lalu satu per satu
- Tandai masing-masing: Selesai / Sedang berjalan / Dibatalkan (alasan singkat untuk yang dibatalkan)
- Bawa item yang belum tuntas ke sprint berikutnya; jangan memperkarakannya ulang sekarang
Bagian 2 — Cuplikan data (5 menit)
- Velocity sprint vs. target
- Pekerjaan tak terencana yang melebihi satu hari
- Insiden atau kejadian on-call
- Perubahan cakupan di tengah sprint
- Tampilkan datanya di layar tanpa diskusi dulu
Bagian 3 — Apa yang berjalan baik (10 menit)
- Tim menambahkan item secara asinkron sebelum rapat atau dalam 3 menit pertama
- Bahas 2-3 teratas; lewati item yang sudah jelas disepakati
- Jangan menghabiskan waktu pada hal yang tak bisa ditindaklanjuti
Bagian 4 — Apa yang perlu diperbaiki (15 menit)
- Format yang sama: masukan asinkron, bahas item bersinyal tertinggi
- Untuk setiap item: kejadian sekali atau pola berulang? Hanya pola yang menjadi action item
- Tugas fasilitator adalah mengubah "ini bikin frustrasi" menjadi sesuatu yang spesifik dan bisa diubah
Bagian 5 — Action item (15 menit)
- Setiap item harus punya: deskripsi, satu pemilik (bukan "timnya"), tanggal jatuh tempo
- Targetkan maksimal 2-3 item; lebih dari itu mengencerkan akuntabilitas
- Bawa maju item apa pun yang belum tuntas dari Bagian 1
Penutup (5 menit)
- +/-/delta singkat atas retro itu sendiri
- Konfirmasi rekap keluar sebelum akhir hari
Apa yang terlewat pada format retro populer
Start/Stop/Continue dan What Went Well/What to Improve/Action Items keduanya format yang valid. Masalahnya bukan formatnya — melainkan bahwa templat jarang menanamkan langkah peninjauan di depan. Langkah itu adalah satu-satunya hal yang menciptakan kesinambungan akuntabilitas dari satu retro ke retro berikutnya. Tanpanya, retro adalah mesin perasaan, bukan mesin perubahan.
Templat juga tak menangani disiplin batas waktu. "Apa yang perlu diperbaiki" hampir selalu molor karena lebih menggugah emosi daripada "apa yang berjalan baik." Tanpa batas tegas, retro 60 menit menjadi 90 menit diskusi dan 5 menit action item yang terburu-buru di akhir. Action item adalah satu-satunya bagian yang mengubah apa pun.
Celah ketiga: action item ditulis sebagai arahan yang samar. "Perbaiki komunikasi frontend-backend" bukan action item. "Sarah akan menjadwalkan sinkronisasi mingguan 30 menit antara lead frontend dan backend, mulai Senin depan" barulah action item. Pemilik dan tanggal mulai harus disebutkan di dalam ruangan — belakangan, hal-hal spesifiknya melunak.
Biaya berlipat dari pola-pola ini muncul berminggu-minggu kemudian sebagai konteks yang tak pernah terekam dan keputusan yang diperkarakan ulang. Pajak rapat membahas bagaimana ini terlihat secara kuantitatif selama satu kuartal.
Mengapa rekap retro lebih sulit ditulis daripada catatan standup
Rekap standup itu pendek. Rekap sprint planning terstruktur. Rekap retrospektif sulit karena kontennya berantakan — sticky note, diskusi yang melompat antarbagian, campuran sentimen dan data. Siapa pun yang menulis rekap harus merekonstruksi benang yang koheren dari rapat yang bergerak ke banyak arah sekaligus.
Pavleur menangani ini dengan baik justru karena keberantakan itu. Ia menangkap semua yang diucapkan selama rapat dan apa pun yang ada di layar — board bersama, grafik velocity dari Bagian 2, tiket insiden yang dirujuk seseorang di Bagian 4. Laporan pasca-rapat terstruktur, dengan action item yang diekstrak dari apa yang benar-benar diputuskan di dalam ruangan (beserta pemilik dan tanggal, sebagaimana disebutkan). Tanpa rekonstruksi, tanpa pembersihan setelah panggilan.
Alat transkripsi berbasis audio saja menangkap kata-katanya tetapi bukan konteks visualnya. Dalam retro, visual kerap merupakan bagian terpenting — board sticky note, grafik yang memunculkan sebuah pola, tiket yang menjadi jangkar diskusi. Konteks itu tidak ada dalam rekap berbasis audio saja. Untuk perbandingan alat secara langsung: Pavleur vs. alternatif.
Pola kegagalan retro yang umum
Action item yang sama muncul dalam tiga retro berturut-turut. Bagian 1 tidak bisa ditawar. Jika sebuah item terus tak terlaksana, entah batalkan dengan alasan yang dinyatakan atau eskalasikan — jangan membawanya maju tanpa henti.
Diskusi berubah menjadi keluh kesah tanpa penyelesaian. Tugas fasilitator di Bagian 4 adalah menerjemahkan "proses itu rusak" menjadi satu hal yang spesifik dan bisa diubah. Jika tak bisa dibuat spesifik dalam 30 detik, masuk ke parking lot.
Tak seorang pun menambahkan item secara asinkron sebelum rapat. Kirim board 24 jam sebelumnya. Isi awali dengan 2-3 item untuk memecahkan masalah kanvas kosong. Rapat berjalan lebih baik ketika semua orang datang dengan sesuatu yang sudah dituliskan.