Cara sprint planning untuk tim kecil: contoh satu minggu
Langkah sprint planning untuk tim kecil: menulis Sprint Goal, menghitung kapasitas, memilih task, dan agenda rapat. Lengkap dengan contoh tim tiga orang.
Sprint planning membantu tim memilih hasil yang ingin dicapai dalam periode kerja tertentu. Untuk tim kecil, rencana harus mempertimbangkan pekerjaan support, review, dan pengujian, bukan hanya waktu mengerjakan task utama. Rencana yang terlalu optimis membuat sprint gagal sejak hari pertama, dan tim kehilangan kepercayaan pada prosesnya.
Panduan ini memakai contoh sprint satu minggu untuk tim tiga orang. Sesuaikan durasi dengan ritme tim, bukan karena sebuah alat mewajibkannya. Jika Anda belum mengenal Scrum, baca dulu apa itu Scrum.
Apa itu sprint planning?
Sprint planning adalah ceremony di awal setiap sprint. Dalam Scrum, rapat ini menjawab tiga pertanyaan:
- Mengapa sprint ini bernilai? Tim menyepakati Sprint Goal.
- Apa yang bisa diselesaikan? Tim memilih item backlog yang mendukung Sprint Goal.
- Bagaimana pekerjaannya dilakukan? Tim memecah item menjadi task yang konkret.
Untuk sprint satu bulan, Scrum Guide memberi batas maksimal delapan jam. Tim kecil dengan sprint satu minggu biasanya cukup satu jam, terutama jika backlog sudah dirapikan sebelumnya lewat refinement. Ceremony lain dalam sprint dijelaskan di panduan Scrum ceremonies.
Sebelum rapat: siapkan backlog
Sprint planning yang lancar dimulai sebelum rapat. Pastikan:
- Item teratas backlog sudah diurutkan oleh pemilik prioritas.
- Item tersebut punya deskripsi dan acceptance criteria. Lihat cara menulis task yang jelas.
- Item yang terlalu besar sudah dipecah.
- Kalender tim untuk minggu depan sudah diketahui: cuti, libur nasional, dan rapat penting.
Jika persiapan ini dilewatkan, sprint planning berubah menjadi sesi memperjelas kebutuhan yang memakan waktu berjam-jam.
Langkah 1: mulai dari tujuan yang dapat diperiksa
Contoh Sprint Goal: “Pengguna yang diundang dapat bergabung tanpa bantuan administrator.” Tujuan ini memberi batas pada task yang akan dipilih. Mengganti warna seluruh dashboard mungkin berguna, tetapi tidak mendukung tujuan tersebut. Simpan pekerjaan itu di backlog untuk dipertimbangkan kemudian.
Sprint Goal yang baik:
- Bisa diperiksa di akhir sprint dengan jawaban ya atau tidak.
- Menjelaskan hasil bagi pengguna atau bisnis, bukan daftar task.
- Cukup kecil untuk dicapai dalam satu sprint.
Langkah 2: hitung kapasitas sebelum mengambil task
Dua developer memiliki masing-masing lima hari kerja. Satu hari dipakai untuk support dan satu hari untuk review serta rapat, sehingga setiap orang memiliki sekitar tiga hari fokus. Angka enam hari fokus adalah asumsi perencanaan, bukan janji kapasitas pasti. Penguji memiliki dua hari tersedia; jadwalkan hasil yang bisa diuji sebelum hari terakhir.
| Anggota | Hari kerja | Support | Review dan rapat | Hari fokus |
|---|---|---|---|---|
| Developer A | 5 | 1 | 1 | 3 |
| Developer B | 5 | 1 | 1 | 3 |
| Penguji | 2 | 0 | 0,5 | 1,5 |
Jangan lupa memperhitungkan libur nasional dan cuti bersama. Minggu dengan tanggal merah bisa mengurangi kapasitas hingga 20–40%.
Langkah 3: pilih dan pecah task
- Tinjau pekerjaan yang masih berjalan dari sprint sebelumnya.
- Pilih tiga atau empat item yang langsung mendukung Sprint Goal.
- Pecah item yang terlalu besar atau memiliki ketergantungan belum selesai.
- Sepakati pemilik, urutan pengerjaan, dan kondisi selesai.
- Sisakan ruang untuk temuan pengujian, lalu catat asumsi yang perlu ditinjau.
Untuk contoh undangan pengguna, task yang dipilih adalah: pengiriman email undangan, halaman penerimaan undangan, pesan untuk tautan kedaluwarsa, dan pengujian alur dari awal sampai akhir. Perkiraan totalnya lima hari fokus, menyisakan satu hari cadangan dari enam hari tersedia.
Agenda sprint planning 60 menit
| Waktu | Kegiatan |
|---|---|
| 0–10 menit | Pemilik prioritas menjelaskan konteks dan usulan Sprint Goal |
| 10–20 menit | Tim menghitung kapasitas dan meninjau pekerjaan yang tersisa |
| 20–45 menit | Memilih item backlog, membahas pertanyaan dan risiko |
| 45–55 menit | Menentukan pemilik dan urutan, memecah item pertama |
| 55–60 menit | Membaca ulang Sprint Goal dan memastikan semua setuju |
Estimasi: hari fokus atau story point?
Banyak tim Scrum memakai story point, yaitu ukuran relatif untuk kompleksitas dan ketidakpastian. Tim kecil sering lebih mudah memulai dengan perkiraan hari fokus karena langsung terhubung dengan kapasitas. Apa pun pilihannya, gunakan estimasi sebagai alat diskusi, bukan janji. Jika dua orang memberi estimasi sangat berbeda, itu tanda ada pemahaman yang belum sama.
Langkah 4: jalankan rencana di Moovit
Buka Sprints dan buat sprint dengan tanggal mulai serta selesai. Pilih task yang akan dimasukkan. Di detail task, periksa Sprint untuk memastikan hubungan dengan sprint yang benar. Tujuan dan kapasitas dapat dicatat menggunakan template sprint planning; Moovit tidak otomatis menghitung kapasitas orang dari kalender.
Selama sprint: jaga fokus
- Lihat board bersama setiap hari selama 10–15 menit.
- Jika ada pekerjaan mendadak, bahas dampaknya terhadap Sprint Goal sebelum mengambilnya.
- Jika Sprint Goal tidak mungkin tercapai, diskusikan dengan pemilik prioritas untuk mengurangi scope, bukan diam-diam lembur.
Akhiri dengan inspeksi hasil
Pada akhir minggu, uji alur undangan dari awal sampai akhir. Jika ada pekerjaan yang belum selesai, catat penyebabnya sebelum memindahkannya. Gunakan temuan itu untuk mengurangi scope atau memperjelas ketergantungan pada sprint berikutnya. Jangan memakai jumlah task selesai sebagai ukuran tunggal kontribusi seseorang.
Kesalahan yang sering terjadi
- Mengisi sprint sampai 100% kapasitas. Selalu sisakan ruang untuk hal tak terduga.
- Tidak punya Sprint Goal. Sprint hanya menjadi daftar task tanpa prioritas.
- Memilih task yang belum jelas. Task tanpa acceptance criteria akan memakan waktu lebih lama dari perkiraan.
- Mengabaikan sisa pekerjaan sprint sebelumnya. Pekerjaan yang belum selesai tetap memakan kapasitas.
- Satu orang menentukan semuanya. Developers yang memilih jumlah pekerjaan; pemilik prioritas menentukan urutan.
Pertanyaan yang sering diajukan
Siapa yang wajib hadir di sprint planning?
Seluruh Scrum Team: Product Owner, Scrum Master, dan Developers. Di tim kecil tanpa peran formal, hadirkan pemilik prioritas dan semua orang yang akan mengerjakan task di sprint tersebut.
Bagaimana jika Sprint Goal tidak tercapai?
Itu informasi, bukan kegagalan pribadi. Bahas penyebabnya di retrospective: apakah kapasitas terlalu optimis, ada pekerjaan mendadak, atau task belum jelas? Gunakan jawabannya untuk memperbaiki perencanaan sprint berikutnya.
Bolehkah menambah task di tengah sprint?
Boleh jika masih mendukung Sprint Goal dan ada kapasitas. Untuk pekerjaan mendadak yang tidak terkait, diskusikan dengan pemilik prioritas: apa yang dikeluarkan dari sprint untuk memberi ruang?
Susun product backlog sebelum sesi berikutnya. Buka Moovit untuk mulai menata task sprint pertama.