Sprint Planning: Cara Menjalankan Meeting Sprint Planning yang Efektif

Sprint planning adalah acara yang mengubah Backlog ide menjadi rencana yang jelas dan berkomitmen yang benar-benar dapat dieksekusi tim. Jika dilakukan dengan baik, membutuhkan waktu kurang dari dua jam dan meninggalkan tim dengan semangat. Jika dilakukan dengan buruk, melebar sampai sore dan menghasilkan daftar yang tidak dipercaya siapapun.

Apa itu sprint planning?

Sprint planning adalah acara berbatas waktu dalam Scrum di mana tim pengembang, Product Owner, dan Scrum Master bertemu di awal setiap Sprint untuk memutuskan pekerjaan apa yang akan diselesaikan dan bagaimana cara melakukannya. Meeting ini menghasilkan dua output: tujuan Sprint (alasan "mengapa") dan Sprint Backlog (item spesifik yang dipilih tim untuk memenuhi tujuan tersebut).

Sprint planning berada dalam kerangka metodologi agile yang lebih luas. Sprint adalah siklus berdurasi pendek dan tetap (biasanya satu hingga empat minggu) yang memberi tim ritme teratur untuk menghasilkan perangkat lunak yang berfungsi atau increment pekerjaan yang selesai. Sprint planning adalah cara setiap siklus dimulai dengan niat daripada asumsi.

Panduan Scrum mendefinisikan dua pertanyaan inti untuk setiap sesi sprint planning: apa yang dapat diserahkan dari Product Backlog selama Sprint ini, dan bagaimana pekerjaan yang dipilih akan diselesaikan? Dua pertanyaan tersebut langsung dipetakan ke dua bagian meeting, yang komunitas Scrum sering sebut sebagai "Bagian 1: Apa" dan "Bagian 2: Bagaimana."

Meeting sprint planning yang berjalan baik bersifat spesifik tentang ruang lingkup, jujur tentang kapasitas, dan didasarkan pada tujuan Sprint yang memberi tim satu titik fokus untuk dua minggu ke depan.

Key Facts

• Panduan Scrum mengalokasikan hingga 8 jam untuk sprint planning dalam Sprint 1 bulan, diskalakan secara proporsional untuk Sprint yang lebih pendek (Panduan Scrum, 2020).
• Tim yang menetapkan tujuan Sprint yang jelas 2,5x lebih mungkin untuk menyelesaikan komitmen Sprint penuh (State of Agile Report edisi ke-17, 2024).
• Sprint planning mengonsumsi sekitar 5% jam kerja Sprint 2 minggu ketika dijalankan secara efisien (data komunitas Scrum.org, 2024).

Mengapa sprint planning penting

Tanpa sprint planning, tim kembali ke prioritisasi ad-hoc. Pekerjaan diambil berdasarkan siapa yang paling keras meminta, bukan apa yang paling penting. Sprint planning memutus pola tersebut dengan menciptakan komitmen bersama sebelum pekerjaan dimulai, bukan sesudahnya.

Manfaatnya terlihat dalam cara yang terukur. Tim dengan tujuan Sprint yang jelas memiliki lebih sedikit perubahan arah di tengah Sprint karena semua orang sudah menyepakati seperti apa "selesai" untuk siklus ini. Perencanaan kapasitas (dilakukan dengan benar selama sprint planning) mencegah tim dari over-commit, yang merupakan penyebab tunggal terbesar kegagalan Sprint. Dan ritual itu sendiri membangun keamanan psikologis: ketika tim berkomitmen bersama, mereka lebih mungkin mengangkat hambatan lebih awal daripada menyembunyikannya hingga hari terakhir.

Sprint planning juga menciptakan hubungan langsung antara pekerjaan sehari-hari dan Roadmap produk. Setiap tujuan Sprint harus dipetakan ke tujuan strategis yang lebih besar. Ketika tim melihat koneksi tersebut dinyatakan secara eksplisit di awal setiap Sprint, pekerjaan terasa lebih seperti kemajuan daripada sekadar daftar tugas.

Bagi tim yang beralih dari metodologi waterfall, sprint planning sering kali merupakan bukti paling jelas bahwa pengiriman agile bekerja secara berbeda. Alih-alih rencana enam bulan yang diberikan dari atas, tim membentuk dua minggu ke depan sendiri, dengan visibilitas penuh ke apa yang mereka setujui.

Dua bagian sprint planning

Panduan Scrum menyusun sprint planning menjadi dua percakapan yang berbeda. Sebagian besar meeting sprint planning yang gagal runtuh karena tim langsung ke Bagian 2 sebelum Bagian 1 benar-benar terselesaikan.

Bagian 1: Apa yang akan kita lakukan? (tujuan Sprint dan pemilihan item)

Product Owner mempresentasikan item teratas dari Product Backlog yang telah diprioritaskan. Tim mengajukan pertanyaan tentang ruang lingkup, kriteria penerimaan, dan ketergantungan. Bersama-sama, mereka menyusun tujuan Sprint: pernyataan tunggal yang ringkas tentang apa yang harus dicapai Sprint ini dari perspektif pemangku kepentingan. Setelah tujuan ditetapkan, tim memilih Product Backlog Items (PBI) yang, jika diselesaikan, akan mencapai tujuan tersebut.

Bagian 1 selesai ketika tim menyepakati tujuan Sprint dan memiliki daftar kandidat item. Hanya itu. Jangan melanjutkan sampai kedua output tersebut ada.

Bagian 2: Bagaimana kita akan melakukannya? (penguraian tugas dan pemeriksaan kapasitas)

Dengan item yang dipilih di atas meja, tim memecah masing-masing item menjadi tugas konkret (biasanya setengah hingga dua hari upaya masing-masing). Di sinilah perencanaan kapasitas terjadi: tim memeriksa apakah tugas-tugas tersebut sesuai dengan jam atau Story Point Sprint yang tersedia mengingat ketersediaan aktual mereka. Item yang tidak muat dikembalikan ke Backlog.

Bagian 2 menghasilkan Sprint Backlog: tujuan Sprint ditambah item yang dipilih ditambah perincian tugas. Ini adalah rencana operasional tim untuk Sprint berikutnya.

Agenda sprint planning (meeting 2 jam)

Tabel di bawah menunjukkan agenda dua jam untuk Sprint dua minggu. Skalakan waktu secara proporsional untuk Sprint yang lebih pendek atau lebih panjang.

Jika meeting berjalan lebih dari dua jam untuk Sprint dua minggu, hentikan dan diagnosa. Penyebab umum: item Backlog belum dirapikan sebelum meeting, tujuan Sprint belum disepakati sebelum beralih ke pemilihan item, atau terlalu banyak item yang kurang terspesifikasi.

Cara menjalankan meeting sprint planning: langkah demi langkah

Langkah 1: Hitung kapasitas sebelum meeting dimulai

Sebelum siapapun duduk, Scrum Master (atau siapapun yang memfasilitasi) menghitung kapasitas yang tersedia tim untuk Sprint. Ini bukan "semua orang bekerja 10 hari jadi kita punya 10 hari kapasitas per orang." Ini memperhitungkan meeting, liburan, tugas on-call, dan faktor fokus (persentase realistis waktu yang dihabiskan untuk pekerjaan Sprint vs. gangguan).

Tabel kapasitas sederhana (dibahas mendalam di bagian berikutnya) membutuhkan lima menit untuk dibangun dan menghemat empat puluh menit perdebatan di tengah meeting.

Langkah 2: Konfirmasi item Backlog memenuhi definition of ready

Sebelum item dapat dipilih untuk Sprint, item harus melewati definition of ready (DoR). DoR adalah daftar periksa yang ditentukan tim yang harus dipenuhi item Backlog sebelum sprint planning. Kriteria tipikal meliputi:

• Kriteria penerimaan ditulis dan dipahami oleh tim
• Ketergantungan teridentifikasi dan tidak terblokir (atau risikonya diketahui)
• Item diestimasi (Story Point atau ukuran kaos)
• Tidak ada item tunggal yang melampaui setengah panjang Sprint

Item yang gagal DoR ditandai dalam Backlog dan dikembalikan ke Product Owner untuk penyempurnaan. Jangan masukkan ke dalam Sprint.

Langkah 3: Susun tujuan Sprint bersama-sama

Product Owner mengusulkan draf tujuan Sprint. Tim menyempurnakan bahasa sampai mencerminkan apa yang sebenarnya dibangun tim, bukan hanya apa yang ingin dilihat bisnis. Tujuan Sprint yang baik adalah:

• Cukup spesifik untuk dapat difalsifikasi (Anda dapat mengetahui di akhir Sprint apakah Anda mencapainya)
• Cukup fleksibel untuk memungkinkan beberapa PBI ditukar jika sesuatu yang tidak terduga muncul
• Satu benang tunggal (satu tujuan per Sprint; beberapa tujuan mengencerkan fokus)

Contoh tujuan Sprint yang lemah: "Tingkatkan alur onboarding." Contoh tujuan Sprint yang kuat: "Pengguna baru dapat mengaktifkan akun mereka dan menyelesaikan tindakan utama pertama mereka tanpa menghubungi dukungan."

Langkah 4: Pilih Product Backlog Items

Dengan tujuan Sprint yang disepakati, tim memilih PBI dari bagian atas Backlog yang paling mendukung tujuan. Ini adalah percakapan, bukan unduhan: tim mengajukan pertanyaan, menegosiasikan ruang lingkup, dan kadang memecah item besar menjadi yang lebih kecil agar sesuai dengan Sprint.

Gunakan Velocity (rata-rata Story Point yang diselesaikan tim per Sprint selama tiga hingga lima Sprint terakhir) sebagai batas maksimum untuk pemilihan. Jangan pilih lebih dari Velocity. Jika tim rata-rata 32 poin per Sprint, jangan memuat 45.

Langkah 5: Urai item menjadi tugas

Untuk setiap PBI yang dipilih, tim mencantumkan tugas konkret yang diperlukan untuk memenuhi kriteria penerimaan. Tugas harus cukup kecil sehingga kemajuannya terlihat setiap hari (sekitar 0,5 hingga 2 hari masing-masing). Penguraian ini juga mengungkap kompleksitas tersembunyi: cerita yang terlihat seperti 3 poin kadang mengungkap lima tugas dengan estimasi gabungan yang jauh lebih tinggi.

Jika daftar tugas sebuah cerita mendorongnya jauh melampaui estimasi awal, tim dapat melakukan re-estimasi, memecah cerita, atau mengembalikannya ke Backlog. Lebih baik mengambil keputusan itu sekarang daripada di hari kedelapan Sprint.

Langkah 6: Berkomitmen dan tutup

Tim melakukan pemeriksaan kapasitas akhir: total estimasi upaya tugas vs. kapasitas Sprint yang tersedia. Jika sesuai, tim berkomitmen. Jika tidak, item dikeluarkan (tidak pernah ditambahkan). Scrum Master mencatat Sprint Backlog dan mencatat pertanyaan terbuka atau ketergantungan yang perlu ditindaklanjuti pada hari pertama.

Komitmen di sini bukan berarti kontrak. Ini berarti tim benar-benar percaya bahwa item-item ini dapat dicapai mengingat apa yang mereka ketahui saat ini. Perbedaan itu penting, terutama dalam tim yang pernah terbakar oleh janji berlebihan.

Perencanaan kapasitas: matematikanya

Perencanaan kapasitas adalah aritmatika sederhana, tetapi mudah salah jika Anda melewatkan faktor fokus.

Rumusnya:

Kapasitas yang Tersedia (poin) = Hari yang Tersedia x Faktor Fokus x Poin per Hari

Faktor fokus mewakili fraksi realistis setiap hari kerja yang dihabiskan untuk pekerjaan Sprint (sebagai lawan dari meeting, email, tiket dukungan, dan gangguan lainnya). Untuk sebagian besar tim, nilainya antara 0,6 dan 0,8. Tim baru atau tim dengan beban dukungan tinggi cenderung ke ujung yang lebih rendah.

Contoh tabel kapasitas untuk Sprint 2 minggu (10 hari kerja):

Dalam contoh ini, batas Velocity tim adalah 53 Story Point. Jika Velocity historis tim adalah 40 poin, gunakan 40 sebagai batas praktis: Velocity memperhitungkan pekerjaan yang terjebak atau menjadi lebih kompleks dari yang diharapkan bahkan ketika orang tersedia.

Jangan pernah menggunakan hari kerja mentah sebagai proksi kapasitas. Tim yang terdiri dari lima developer masing-masing bekerja 10 hari tidak memiliki 50 hari kapasitas Sprint. Faktor fokus ada untuk membuat perencanaan jujur.

Contoh sprint planning berdasarkan jenis tim

Pendekatan struktur rincian kerja bekerja dengan baik untuk memecah item Sprint besar menjadi komponen tingkat tugas, terutama untuk tim rekayasa dan desain di mana cerita memiliki beberapa sub-tugas teknis.

Kesalahan sprint planning yang umum (dan solusinya)

Praktik terbaik sprint planning

• Batasi waktu dan hormati batasnya. Sprint dua minggu mendapat meeting perencanaan dua jam. Ketika meeting melebihi waktu, itu menandakan masalah proses (Backlog kurang dirapikan, tujuan tidak jelas), bukan masalah beban kerja.
• Rapikan Backlog sebelum sprint planning. Meeting sprint planning terbaik terasa hampir terlalu mudah karena item sudah dipahami dengan baik. Jalankan sesi penyempurnaan pertengahan Sprint untuk mem-pre-groom 10 hingga 15 item teratas.
• Tulis tujuan Sprint di dinding (atau dalam dokumen bersama). Tujuan yang hanya ada dalam ingatan seseorang berhenti memandu keputusan pada hari ketiga. Tempatkan di suatu tempat yang dilihat seluruh tim setiap hari.
• Gunakan skala estimasi yang konsisten. Apakah Anda menggunakan Story Point, ukuran kaos, atau hari ideal, pilih satu dan pertahankan di seluruh Sprint agar perbandingan Velocity tetap bermakna.
• Sertakan seluruh tim Scrum, tidak ada orang lain. Sprint planning adalah untuk Product Owner, Scrum Master, dan tim pengembang. Pemangku kepentingan, manajer, dan eksekutif bukan peserta. Masukan mereka harus datang melalui Backlog, bukan meeting.
• Mulai dengan perspektif siklus hidup proyek untuk aliran baru. Untuk tim yang memulai produk atau inisiatif baru, mendasarkan tujuan Sprint pertama dalam siklus hidup proyek yang lebih luas membantu tim memahami bagaimana Sprint ini terhubung dengan lengkungan pengiriman.
• Debriefing dalam retrospektif. Jika tim secara konsisten melewatkan tujuan Sprint, itu adalah masalah sprint planning. Retrospektif harus memeriksa akurasi perencanaan di samping kinerja pengiriman.
• Latih silang mengenai trade-off Scrum vs. Kanban. Tim yang memahami kedua metode membuat keputusan sprint planning yang lebih baik, terutama ketika mereka memutuskan apakah struktur Sprint bahkan merupakan pilihan yang tepat untuk jenis pekerjaan mereka.

Pertanyaan yang sering diajukan

Berapa lama sprint planning seharusnya?

Panduan Scrum menetapkan maksimum 8 jam untuk Sprint satu bulan, diskalakan secara proporsional untuk Sprint yang lebih pendek. Untuk Sprint dua minggu, itu berarti maksimum 4 jam, meskipun tim yang mempersiapkan diri dengan baik secara rutin selesai dalam 2 jam atau kurang. Jika sprint planning Anda secara konsisten berjalan lama, pelakunya hampir selalu adalah Backlog yang kurang dirapikan atau tujuan Sprint yang belum diselaraskan tim sebelum meeting dimulai.

Apa itu definition of ready?

Definition of ready (DoR) adalah daftar periksa yang ditentukan tim yang harus dipenuhi Product Backlog Item sebelum memenuhi syarat untuk sprint planning. Kriteria DoR umum mencakup kriteria penerimaan tertulis, estimasi Story Point, ketergantungan yang teridentifikasi, dan ruang lingkup yang cukup kecil untuk muat dalam satu Sprint. DoR bukan konsep dalam Panduan Scrum tetapi praktik yang diadopsi secara luas yang mencegah tim menarik cerita yang belum benar-benar siap dikerjakan. Tim menyepakati DoR mereka dalam retrospektif dan memperbaruinya seiring belajar.

Siapa yang menghadiri sprint planning?

Peserta yang diwajibkan adalah Product Owner, Scrum Master, dan seluruh tim pengembang. Product Owner mempresentasikan dan memprioritaskan item Backlog; tim pengembang mengajukan pertanyaan, mengestimasi, dan memilih item; Scrum Master memfasilitasi dan menghilangkan hambatan proses. Manajer, pemangku kepentingan, dan pelanggan tidak hadir. Kebutuhan mereka diwakili melalui item Product Backlog yang dibawa Product Owner ke meeting.

Apa perbedaan antara sprint planning dan backlog refinement?

Backlog refinement (kadang disebut backlog grooming) adalah aktivitas berkelanjutan di mana Product Owner dan tim meninjau, mengestimasi, dan mengklarifikasi item Backlog yang akan datang sebelum diperlukan untuk sprint planning. Sprint planning adalah meeting formal berbatas waktu yang membuka setiap Sprint. Pikirkan penyempurnaan sebagai persiapan dan sprint planning sebagai meeting pengambilan keputusan. Tim yang melewatkan penyempurnaan menghabiskan meeting sprint planning untuk melakukan kedua pekerjaan sekaligus, itulah mengapa sesi tersebut berjalan lama dan menghasilkan komitmen yang tidak pasti.

Apa yang terjadi jika tim tidak dapat berkomitmen pada pekerjaan yang cukup?

Jika kapasitas tim lebih rendah dari biasanya (liburan, sakit, prioritas yang bersaing), sprint planning harus mencerminkan hal itu dengan jujur. Pilih lebih sedikit item, tetapkan tujuan Sprint yang lebih kecil, dan komunikasikan ruang lingkup yang berkurang kepada pemangku kepentingan sebelum Sprint dimulai. Jangan mengisi Sprint berkapasitas rendah dengan tujuan ambisius atau item yang tidak dipercaya tim dapat diselesaikan. Ruang lingkup yang berkomitmen lebih kecil yang berhasil dikirimkan jauh lebih baik daripada ruang lingkup ambisius yang sebagian dikirimkan dan membuat pemangku kepentingan tidak pasti tentang apa yang benar-benar sudah selesai.

---

Sprint planning yang efektif bukan tentang memasukkan sebanyak mungkin pekerjaan ke dalam dua minggu. Ini tentang memilih pekerjaan yang tepat, menyepakati mengapa itu penting, dan membangun keyakinan bersama bahwa tim dapat menyelesaikan apa yang mereka janjikan. Ketika sprint planning berjalan dengan baik, Sprint hampir berjalan sendiri, dan itulah tepatnya seperti apa rasanya.