Templat Agenda Sprint Planning untuk Tim Engineering

Mengapa sprint kelebihan beban

Sprint planning punya satu kegagalan struktural yang tak dicegah templat: tim memilih backlog sprint sebelum ada yang memeriksa kapasitas. Hasilnya adalah sprint yang tampak bisa dicapai di papan tulis dan runtuh pada hari Rabu ketika dua engineer absen separuh minggu, satu tiket melipatgandakan cakupannya tiga kali, dan tiga item punya dependensi tak tersebut pada sebuah layanan yang sedang ditulis ulang tim platform.

Perbaikannya sederhana dan hampir tak pernah dilakukan: berkomitmen pada kapasitas sebelum berkomitmen pada pekerjaan. Templat di bawah ini dibuka dengan tinjauan kapasitas justru untuk alasan itu.

Agendanya (salin-tempel ini)

Durasi: 2 jam untuk sprint 2 minggu; 1 jam untuk sprint 1 minggu
Format: Difasilitasi, dengan backlog terlihat oleh seluruh tim

Bagian 1 — Tujuan sprint (10 menit)

Satu kalimat: seperti apa sprint yang sukses jika dilihat dari luar?
Tujuan harus cukup spesifik sehingga anggota tim mana pun bisa menilai di akhir sprint apakah Anda mencapainya
Tolak tujuan yang hanya berupa daftar tiket ("selesaikan refactor auth dan halaman billing") — itu backlog, bukan tujuan

Bagian 2 — Tinjauan kapasitas (15 menit)

Daftar setiap anggota tim beserta namanya
Untuk masing-masing: cuti terencana, rotasi on-call, rapat rutin, komitmen eksternal yang diketahui
Nyatakan kapasitas sebagai story point atau hari yang tersedia — bukan jumlah kepala
Angka ini adalah batas atas; jangan memilih pekerjaan lebih banyak dari yang didukungnya

Bagian 3 — Pemilihan backlog (45 menit)

Telusuri item berprioritas tertinggi dari backlog yang sudah dirapikan
Untuk setiap kandidat: apakah tim punya cukup untuk memulainya, atau ada pertanyaan terbuka yang butuh jawaban sebelum sprint dimulai? Pertanyaan terbuka masuk ke antrean refinement, bukan sprint
Berhenti memilih ketika Anda mencapai 80% kapasitas; sisa 20% menyerap luapan dan pekerjaan tak terencana

Bagian 4 — Kriteria penerimaan (20 menit)

Untuk setiap item terpilih: nyatakan kriteria yang membuatnya selesai
Jika tim tak bisa menyatakan kriteria dalam 60 detik, tiket itu belum cukup dirapikan — kembalikan ke backlog
Tuliskan di tiket sekarang, di dalam ruangan; jangan mengandalkan "kita tambahkan nanti"

Bagian 5 — Risiko dan dependensi (15 menit)

Apa yang bisa memblokir penyelesaian tujuan sprint yang tidak dikendalikan tim?
Sebutkan pemilik dependensinya; munculkan sekarang selagi ada waktu menyelesaikannya sebelum tengah sprint
Dependensi yang belum terselesaikan mendapat pemilik yang disebut namanya dari tim yang akan melacaknya

Penutup (15 menit)

Konfirmasi tujuan sprint masih valid mengingat pekerjaan yang terpilih
Tugaskan notulis rekap sprint, atau konfirmasi pengaturan laporan otomatis
Konfirmasi tanggal planning berikutnya

Apa yang terlewat pada kebanyakan templat sprint planning

Templat sprint planning yang paling populer berfokus pada perapian backlog dan definition-of-done. Keduanya penting. Tak satu pun menangani kesalahan planning yang menghasilkan paling banyak kegagalan sprint: memilih pekerjaan tanpa memeriksa ketersediaan.

Sebuah tim beranggotakan lima engineer pada kapasitas penuh punya sekitar 200 story point tersedia per sprint 2 minggu. Tim beranggotakan lima dengan dua engineer cuti, satu berotasi on-call, dan satu dalam offsite tiga hari mungkin punya sekitar 110. Jika Anda memilih 180 poin pada sprint kedua, Anda sudah gagal sejak awal. Langkah pemilihan adalah tempat kelebihan komitmen terjadi, dan kapasitas harus mendahuluinya.

Celah kedua adalah kriteria penerimaan. Tim bergerak cepat melewati planning dan berniat menulis kriteria nanti. Nanti tidak terjadi pada tingkat kespesifikan yang sama. Orang yang tadinya menulis kriteria yang presisi di dalam ruangan menulis sesuatu yang lebih samar dari ingatan keesokan harinya, atau tidak menulisnya sama sekali. Perselisihan di tengah sprint soal apa arti "selesai" hampir selalu bisa ditelusuri ke kriteria penerimaan yang dilewatkan saat planning.

Biaya berlipat dari celah-celah ini — sprint kelebihan beban, temuan di tengah sprint, definisi yang diperkarakan ulang — terlihat jelas ketika Anda menjumlahkannya: Pajak rapat.

Mengapa catatan sprint planning lebih sulit dari yang terlihat

Sprint planning menghasilkan informasi lebih banyak daripada hampir semua rapat rutin lain: tujuan sprint, angka kapasitas, alasan pemilihan item demi item, kriteria penerimaan per tiket, pemilik dependensi, item risiko. Menulis rekap yang berguna menuntut penangkapan semua itu dalam bentuk yang berguna tiga hari kemudian ketika seseorang bertanya "kenapa kita memotong item itu?"

Pavleur membuat laporan sprint planning secara otomatis di akhir panggilan. Ia menangkap tujuan sprint, backlog terpilih beserta alasannya, kriteria penerimaan sebagaimana dinyatakan dalam rapat, dan pemilik dependensi sebagaimana disebutkan. Jika seseorang membagikan layar backlog atau spreadsheet kapasitas, visual itu disertakan dalam laporan berdampingan dengan diskusi — konteks yang akan sepenuhnya terlewat oleh alat berbasis audio saja seperti Otter atau Fireflies. Siapa pun yang bergabung terlambat atau perlu memeriksa keputusan di tengah sprint punya catatan lengkap. Untuk perbandingan bagaimana ini berbeda dari alat berbasis audio saja: Pavleur vs. alternatif.

Menangani perubahan rencana di tengah sprint

Rencana sprint adalah komitmen, bukan kontrak. Ketika sesuatu di tengah sprint benar-benar membatalkan rencana — sebuah insiden produksi, sebuah dependensi kritis yang memblokir tiga tiket, sebuah pergeseran prioritas dari pimpinan — respons yang tepat adalah panggilan perencanaan ulang yang cepat, bukan pemotongan cakupan secara diam-diam. Panggilan perencanaan ulang memakan 20 menit dan menghasilkan tujuan sprint yang diperbarui yang mencerminkan kenyataan. Alternatifnya adalah sprint yang gagal di atas kertas tetapi disesuaikan secara informal dengan cara yang tak seorang pun menuliskannya, membuat retrospektif lebih sulit dan angka velocity tak bermakna.

Bangun kebiasaan perencanaan ulang yang eksplisit. Gunakan struktur yang sama: kapasitas yang diperbarui, pemilihan yang direvisi, tujuan yang dinyatakan ulang. Itu memakan jauh lebih sedikit waktu daripada kebingungan yang dicegahnya.