Perencanaan sprint: praktik Agile terbaik

Dasar-dasar perencanaan

Perencanaan sprint yang baik butuh pendekatan terstruktur, yang mencakup analisis sprint sebelumnya, penilaian kemampuan tim, dan tujuan yang dirumuskan dengan jelas. Informasi selengkapnya: Perangkat Lunak Manajemen Proyek IT untuk Tim IT.

1. Persiapan untuk perencanaan harus dimulai jauh-jauh hari sebelumnya. Product Owner perlu menyiapkan dan mengurutkan prioritas backlog paling lambat sehari sebelum pertemuan. Tim pengembang juga harus sempat membaca user story lebih dulu dan mengajukan pertanyaan jika ada yang belum jelas.
2. Aturan alokasi klasik: dua jam perencanaan untuk setiap minggu sprint. Artinya, sprint dua minggu mendapat empat jam, walaupun dalam praktik waktu ini sering lebih baik dibagi ke beberapa sesi pendek daripada dihabiskan dalam satu rapat panjang.

Fase persiapan

Perencanaan sprint tidak akan membaik tanpa persiapan yang serius. Tahap ini sering dianggap remeh, padahal justru tahap inilah yang menentukan berhasil tidaknya seluruh proses.

• Definition of Ready (DoR) menetapkan kriteria kapan sebuah user story siap masuk ke sprint. Setiap story perlu punya kriteria penerimaan yang jelas, perkiraan tingkat kesulitan, dan daftar ketergantungan pada tugas lain. Kalau DoR tidak dipatuhi, perencanaan jadi berantakan karena tim sibuk memperjelas story, sementara rencana pengerjaannya tidak tersentuh.
• Backlog refinement harus dilakukan rutin, tidak hanya menjelang perencanaan sprint. Praktik yang umum adalah menyisihkan 10% waktu sprint untuk kegiatan ini. Tim bisa mengadakan sesi refinement singkat beberapa kali seminggu dan sedikit demi sedikit mematangkan story untuk sprint-sprint berikutnya.
• Analisis Velocity memberi tim gambaran yang akurat tentang berapa banyak pekerjaan yang benar-benar bisa mereka selesaikan. Selain Velocity rata-rata dari 3-5 sprint terakhir, perhitungkan juga hal yang bisa memengaruhi produktivitas di sprint berikutnya, seperti cuti yang sudah dijadwalkan, hari libur, utang teknis yang menumpuk, atau ketergantungan pada pihak luar.

Sesi perencanaan

Perencanaan sprint terdiri dari dua tahap: menentukan apa yang akan diselesaikan dalam sprint, lalu menentukan bagaimana pekerjaan itu akan dikerjakan. Keduanya membutuhkan masukan yang berbeda dan menghasilkan keluaran yang berbeda pula. Jika dicampur, kedua tahap sama-sama kehilangan manfaatnya.

1. Tim, bersama dengan Product Owner, merumuskan tujuan sprint yang mengikat semua user story yang dipilih. Tujuan itu harus spesifik, terukur, dan bermakna bagi semua peserta. Contoh tujuan yang lemah: "Tingkatkan pengalaman pengguna." Contoh tujuan yang baik: "Pengguna akan dapat mendaftar melalui media sosial dengan satu klik."
2. Tim pengembangan memecah story yang dipilih menjadi tugas dan memperkirakan durasinya dalam jam. Dari sini biasanya muncul kerumitan dan ketergantungan yang tidak terlihat di tingkat story. Satu tugas sebaiknya tidak lebih dari 8 jam, dan tugas yang melewati batas itu perlu dipecah lagi menjadi subtugas.

Peran dan tanggung jawab

Perencanaan sprint berjalan baik jika setiap peserta memahami perannya dan bekerja di dalam batas peran itu.

• Scrum Master memandu proses, menjaga timebox, dan membantu tim mengambil keputusan. Scrum Master tidak memaksakan jawaban. Tugasnya adalah mengajukan pertanyaan yang tepat dan menjaga diskusi tetap produktif.
• Product Owner bertanggung jawab atas prioritas backlog dan memutuskan fitur mana yang dikerjakan lebih dulu. Ia harus siap menjelaskan nilai bisnis setiap story dan menjawab pertanyaan tim pengembang dengan cukup rinci agar tim bisa membuat estimasi.
• Tim pengembangan berkomitmen untuk memberikan hasil. Komitmen ini harus lahir dari tim sendiri, jangan ditetapkan oleh pihak luar, karena janji yang dibuat tim sendiri menumbuhkan motivasi dan rasa tanggung jawab yang jauh lebih kuat daripada target yang dipaksakan.

Kesalahan umum

• Memperkirakan kemampuan secara berlebihan adalah kesalahan perencanaan sprint yang paling sering terjadi. Tim hampir selalu mengambil pekerjaan lebih banyak daripada yang sanggup mereka selesaikan, terutama di awal proyek atau setelah sprint yang sukses. Pegangannya sederhana: lebih baik berjanji sedikit lalu memberi lebih. Janji yang tidak ditepati mengikis kepercayaan pemangku kepentingan dan menurunkan semangat tim di sprint berikutnya.
• Tidak adanya buffer waktu adalah kesalahan struktural yang kritis. Rencana sprint perlu menyisakan 10-20% waktu sebagai cadangan untuk tugas mendadak, bug, dan permintaan dukungan teknis. Cadangan ini jangan diisi dengan story tambahan sejak awal, karena gunanya memang untuk menampung pekerjaan tak terduga yang selalu muncul di setiap sprint.
• Mengabaikan dependensi menciptakan blocker di tengah sprint. Semua ketergantungan pada pihak luar harus dikenali dan diselesaikan saat perencanaan. Jika sebuah tugas bergantung pada tim lain atau vendor, tenggatnya perlu disepakati dan dikonfirmasi sebelum sprint dimulai.

Pemantauan proses

Tim Agile yang matang terus memperbaiki cara mereka merencanakan. Dalam retrospektif, tim sebaiknya menilai tidak hanya hasil sprint, tetapi juga kualitas perencanaannya sebagai hal tersendiri.

Metrik untuk analisis:

• Akurasi estimasi, yaitu perbandingan waktu yang direncanakan dengan waktu yang benar-benar terpakai untuk setiap story dan tugas
• Persentase cerita yang diselesaikan, yaitu berapa bagian dari story yang dijanjikan benar-benar selesai di akhir sprint
• Jumlah perubahan dalam sprint setelah perencanaan, yang menunjukkan seberapa stabil rencana dan seberapa jelas kebutuhannya
• Waktu yang dihabiskan untuk perencanaan, dibandingkan dengan alokasi standar untuk melihat apakah tim terus-menerus merencanakan terlalu lama atau terlalu singkat

Grafik Burndown menunjukkan kemajuan sepanjang sprint dan memperlihatkan masalah cukup dini sehingga masih bisa diperbaiki. Jika grafik menunjukkan tim tidak akan menyelesaikan pekerjaan yang direncanakan, tim perlu bertindak: menyusun ulang prioritas tugas yang tersisa atau mengeluarkan user story dengan prioritas terendah dari lingkup sprint.

Menyesuaikan perencanaan

• Tim jarak jauh memerlukan adaptasi khusus untuk perencanaan sprint. Siapkan alat kolaborasi yang sesuai, dan pastikan setiap peserta jarak jauh mendapat kesempatan bicara yang sama. Untuk tim yang tersebar, beberapa sesi pendek hampir selalu menghasilkan keterlibatan dan hasil yang lebih baik daripada satu rapat panjang.
• Program besar dengan beberapa tim memerlukan koordinasi di tingkat program. Scrum of Scrums atau SAFe (Scaled Agile Framework) menyediakan cara untuk menyelaraskan perencanaan sprint antartim yang saling bergantung.
• Proyek pemeliharaan, yang sebagian besar waktunya habis untuk dukungan dan perbaikan bug, perlu menyisihkan kapasitas secara tegas untuk pekerjaan tak terencana. Alokasi standar 30-50% kapasitas sprint untuk dukungan, dengan sisanya untuk fitur baru, mencegah tim gagal memenuhi janji karena pekerjaan dukungan dianggap beban sampingan dan tidak masuk hitungan kapasitas.

Artikel terkait:

Untuk kerangka kerja manajemen proyek dan penyeimbangan kendala, baca Segitiga manajemen proyek: Menyeimbangkan ruang lingkup, waktu, dan biaya.

Untuk ikhtisar praktis dari papan Kanban dan manajemen alur kerja visual, baca Apa itu papan Kanban? Panduan untuk manajemen alur kerja visual.

Untuk cara tim Agile menggunakan persona untuk tetap selaras dengan kebutuhan pengguna nyata, baca Persona Agile: Meningkatkan pengembangan berpusat pada pengguna dalam proyek Agile. Baca selengkapnya: Papan Kanban.

Kesimpulan

Perencanaan sprint yang berhasil membutuhkan pendekatan sistematis dan perbaikan terus-menerus yang dilakukan dengan sengaja, tidak ditunda sampai proyek selesai. Retrospektif memberi tim cara untuk menilai hasil sprint sekaligus bahan perencanaan yang membentuknya. Dengan begitu, proses perencanaan ikut diperbaiki sedikit demi sedikit, sama seperti Agile memperbaiki produk.