Ada alasan mengapa ramalan cuaca memberi tahu Anda bahwa ada kemungkinan 70% akan turun hujan, alih-alih menjanjikan bahwa hujan pasti akan turun tepat pukul 3 sore. Mereka menggunakan informasi yang tersedia, memperhitungkan ketidakpastian, dan memperbarui ramalan seiring masuknya data baru. Anda tetap bisa merencanakan sore hari Anda berdasarkan ramalan tersebut, asalkan Anda tidak menganggap ramalan itu sebagai jaminan.
Perencanaan sprint bekerja berdasarkan prinsip yang serupa. Sebuah Tim Scrum memiliki daftar pekerjaan produk (product backlog), perkiraan kapasitas yang tersedia, dan tujuan yang ingin dicapai. Namun, beberapa detail pekerjaan baru menjadi jelas seiring berjalannya sprint. Merencanakan setiap jam ke depan tidak memberikan ruang yang cukup untuk penemuan-penemuan tersebut, sementara memulai tanpa arah yang disepakati bersama membuat lebih sulit untuk memutuskan hal apa yang layak mendapat perhatian.
Tujuannya adalah untuk menyepakati hasil yang bernilai dan memperkirakan seberapa banyak pekerjaan yang dapat diselesaikan tim untuk mencapainya. Dari situ, tim dapat menyesuaikan rencananya seiring dengan bertambahnya pengetahuan tanpa kehilangan fokus pada tujuan sprint.
Panduan ini mencakup persiapan backlog, agenda perencanaan yang terjadwal, perhitungan kapasitas praktis, serta contoh terperinci yang menunjukkan cara menyesuaikan rencana selama sprint.
TL;DR Perencanaan sprint menyatukan Tim Scrum untuk menyepakati satu tujuan sprint, memilih item backlog, dan menetapkan rencana pengiriman awal:
- Persiapkan diri dengan menyempurnakan pekerjaan yang akan datang serta memeriksa ketersediaan, item yang belum selesai, ketergantungan, dan Definisi Selesai
- Dasarkan perkiraan pada kapasitas aktual dan kinerja masa lalu, dengan memperhitungkan cuti, rapat, tugas pendukung, dan ketidakpastian tanpa menghitung komitmen dua kali
- Akhiri sesi perencanaan dengan daftar tugas sprint yang disepakati bersama, lalu sesuaikan rencana pengiriman seiring tim memperoleh pemahaman lebih lanjut sambil tetap menjaga tujuan sprint
- Gunakan contoh agenda berdurasi dua jam dan contoh perhitungan kapasitas yang sudah disusun sebagai titik awal, lalu sesuaikan dengan kebutuhan tim
Apa Itu Perencanaan Sprint?
Perencanaan sprint adalah acara Scrum yang diadakan di awal setiap sprint untuk menyepakati apa yang ingin dicapai oleh tim dan bagaimana tim akan menangani pekerjaan tersebut. Acara ini mengumpulkan seluruh Tim Scrum, termasuk Product Owner, Scrum Master, dan pengembang. Spesialis lain, seperti insinyur keamanan atau pemimpin yang berinteraksi langsung dengan pelanggan, juga dapat ikut serta jika masukan mereka dapat membantu tim mengambil keputusan yang tepat.
Menurut Panduan Scrum, setiap sesi perencanaan harus menghasilkan tiga hal: tujuan sprint yang menjelaskan nilai dari pekerjaan tersebut, pemilihan item backlog produk yang mendukung tujuan tersebut, dan rencana awal untuk menyampaikannya. Ketiga hal ini bersama-sama membentuk backlog sprint, yang terus diperbarui oleh para pengembang seiring berjalannya sprint.
Panduan Scrum menetapkan batas waktu maksimal delapan jam untuk sprint satu bulan, dan sprint yang lebih pendek biasanya membutuhkan waktu lebih sedikit. Dengan backlog yang telah disempurnakan dengan baik, agenda di bawah ini dapat diselesaikan dalam dua jam.
Jika Anda belum familiar dengan beberapa istilah ini, glosarium kami menjelaskan dasar-dasar Agile dan Scrum.
Tiga Pertanyaan yang Dijawab oleh Perencanaan Sprint
Setiap sesi perencanaan sprint berpusat pada tiga pertanyaan:
- Mengapa sprint ini bernilai?
- Apa yang dapat kita capai?
- Lalu, bagaimana kita akan menyelesaikan pekerjaan tersebut?
Panduan Scrum mengatur perencanaan berdasarkan pertanyaan-pertanyaan ini, dimulai dari nilai yang ingin Anda sampaikan. Setelah semua orang memahami hal tersebut, akan lebih mudah untuk memutuskan item backlog mana yang layak mendapat perhatian dan seberapa banyak pekerjaan yang secara wajar dapat ditangani oleh tim Anda.
| Pertanyaan | Siapa yang memimpin | Hasil | Contoh untuk sprint 2 minggu |
|---|---|---|---|
| Mengapa sprint ini bernilai? | Product Owner mengusulkan; seluruh tim menyetujui | Tujuan sprint | Pelanggan baru dapat membayar dengan kartu saat checkout tanpa perlu menghubungi tim penjualan |
| Apa yang dapat dilakukan pada sprint ini? | Pengembang memilih, bersama dengan Pemilik Produk | Item backlog yang dipilih | Formulir pembayaran dengan kartu, integrasi penyedia layanan pembayaran, email tanda terima, penanganan kesalahan |
| Bagaimana pekerjaan yang dipilih akan diselesaikan? | Pengembang | Rencana tugas awal | Item-item tersebut dibagi menjadi tugas-tugas, biasanya masing-masing memakan waktu satu hari atau kurang, dengan tanggung jawab awal yang telah disepakati |
Mengapa sprint itu penting
Tujuan sprint memberikan arah bagi tim dan membantu pemangku kepentingan memahami apa yang diharapkan. Sepakati tujuan ini bersama Tim Scrum Anda sebelum sesi perencanaan berakhir.
Jelaskan hasil yang dapat dikenali oleh orang-orang, seperti “Pengguna uji coba dapat mengundang rekan tim,” daripada target beban kerja seperti “Menyelesaikan 34 story points.” Jika muncul masalah yang tidak terduga, tujuan tersebut membantu tim memutuskan pekerjaan mana yang perlu disesuaikan sambil tetap mempertahankan hasil yang diinginkan.
Baca Selengkapnya: Cara Menulis Sasaran Sprint yang Efektif (+Contoh)
Apa yang dapat diselesaikan oleh tim pada sprint ini
Setelah Anda menyepakati tujuan tersebut, saatnya menentukan apa yang secara realistis dapat diselesaikan oleh tim.
Pengembang memilih item backlog melalui diskusi dengan Product Owner sambil mempertimbangkan kapasitas yang tersedia, kinerja sebelumnya, dan Definisi Selesai. Ini juga merupakan waktu yang tepat untuk meninjau komitmen yang sudah ada yang dapat memengaruhi berapa banyak waktu yang dimiliki tim untuk pekerjaan sprint.
Banyak tim menggunakan story points untuk membandingkan tingkat usaha dan kompleksitas item backlog. Skala Fibonacci dapat membantu mengorganisir diskusi tersebut, terutama ketika tingkat usaha yang diperlukan belum jelas.
Jika Anda baru mengenal story points atau ingin melihat bagaimana story points digunakan dalam praktiknya, berikut ini panduan langkah demi langkah mengenai proses estimasi.
Bagaimana tim akan melaksanakan pekerjaan tersebut
Setelah item backlog dipilih, para pengembang merumuskan cara mengubahnya menjadi peningkatan produk yang selesai dan memenuhi Definisi Selesai. Panduan Scrum menyarankan untuk membagi item yang lebih besar menjadi bagian-bagian pekerjaan yang lebih kecil, yang biasanya berukuran sedemikian rupa sehingga dapat diselesaikan dalam satu hari atau kurang.
Itu tidak berarti Anda harus merinci setiap jam dalam sprint. Beberapa hari pertama mungkin memerlukan rencana yang lebih terperinci, sementara tugas-tugas selanjutnya dapat tetap fleksibel untuk disesuaikan seiring munculnya detail baru. Menganggap perkiraan awal sebagai komitmen yang pasti dapat menekan tim untuk memenuhi angka awal, meskipun cakupan pekerjaan berubah di tengah jalan.
Seperti yang dijelaskan oleh Dave West, CEO Scrum.org:
Perkiraan yang digunakan untuk membenarkan tenggat waktu justru memicu perilaku yang merusak kepercayaan, seperti membesar-besarkan perkiraan, menyembunyikan risiko, atau diam-diam mengubah definisi ‘selesai’ demi mencapai angka tertentu.
Perkiraan yang digunakan untuk membenarkan tenggat waktu justru memicu perilaku yang merusak kepercayaan, seperti membesar-besarkan perkiraan, menyembunyikan risiko, atau diam-diam mengubah definisi ‘selesai’ demi mencapai angka tertentu.
Apa Perbedaan Antara Perencanaan Sprint dan Penyempurnaan Backlog?
Penyempurnaan backlog memberikan pemahaman yang lebih jelas kepada tim Anda mengenai pekerjaan yang akan datang sebelum tiba waktunya untuk memutuskan apa saja yang akan dimasukkan ke dalam sprint berikutnya. Perencanaan sprint dibangun berdasarkan persiapan tersebut untuk menyepakati tujuan, memilih item backlog, dan menetapkan rencana pengiriman awal.
Kedua aktivitas tersebut memiliki tujuan yang berbeda dalam Scrum:
| Dimensi | Penyempurnaan backlog | Perencanaan sprint |
|---|---|---|
| Tujuan | Perjelas, bagi, dan perkirakan item backlog yang akan datang | Tentukan tujuan sprint, pilih pekerjaan, dan rencanakan pengiriman |
| Waktu | Berlangsung sepanjang sprint | Di awal setiap sprint |
| Status Scrum | Kegiatan yang berkelanjutan | Acara Scrum formal dengan batasan waktu |
| Siapa saja yang berpartisipasi | Product Owner dan pengembang yang terkait | Seluruh Tim Scrum |
| Hasil | Item backlog dengan detail, perkiraan, dan cakupan yang lebih jelas | Backlog sprint: tujuan sprint, item yang dipilih, dan rencana pengiriman |
Pastikan cukup banyak item backlog yang akan datang telah disempurnakan sehingga tim memiliki pilihan yang jelas selama perencanaan sprint. Seberapa banyak persiapan yang diperlukan bergantung pada seberapa cepat prioritas berubah dan seberapa besar ketidakpastian yang masih ada. Item yang berada lebih jauh di bagian bawah backlog dapat tetap kurang terperinci hingga mendekati tahap pemilihan.
Baca Juga: Untuk panduan lebih lanjut, lihat artikel kami tentang pemeliharaan backlog serta cara menjaga backlog produk tetap terorganisir dan diprioritaskan.
Cara Mempersiapkan Perencanaan Sprint
Beberapa hari sebelumnya, pastikan daftar pekerjaan (backlog) sudah dalam kondisi baik dan semua orang memiliki informasi yang diperlukan untuk mengambil keputusan. Dengan begitu, Anda dapat memanfaatkan sesi tersebut untuk mendiskusikan apa yang akan diselesaikan dan bagaimana cara mengerjakannya tanpa harus menyelesaikan setiap persyaratan dari awal.
Berikut adalah daftar periksa yang perlu Anda selesaikan sebelum sprint berikutnya:
- Buat draf tujuan sprint: Mintalah Product Owner untuk mengusulkan hasil yang mendukung Tujuan Produk yang lebih luas, sehingga tim memiliki poin-poin konkret untuk dibahas
- Tinjau daftar tugas produk: Pastikan item dengan prioritas tertinggi telah diurutkan, dipahami, dan diperkirakan waktunya jika diperlukan
- Periksa ketersediaan tim: Minta para pengembang untuk membagikan rencana cuti, jadwal giliran dukungan, dan komitmen lain yang dapat memengaruhi kapasitas mereka
- Tinjau kembali pekerjaan yang belum selesai: Tinjau pekerjaan yang terbawa dari sprint sebelumnya dan perbaikan apa pun yang diidentifikasi selama sesi retrospektif
- Identifikasi ketergantungan: Tandai pekerjaan yang memerlukan masukan atau persetujuan dari tim lain, dan jelaskan siapa yang akan mengkoordinasikannya
- Tinjau Definisi Selesai: Pastikan semua orang memahami standar kualitas yang harus dipenuhi oleh setiap item backlog yang telah diselesaikan
Jika Anda menjadwalkan sesi retrospektif sprint dan sesi perencanaan dalam waktu yang berdekatan, pastikan ada cukup waktu untuk diskusi yang memadai di kedua sesi tersebut. Temuan dari retrospektif harus menjadi dasar perencanaan sprint berikutnya, jadi pastikan kedua pertemuan tersebut tidak terasa terburu-buru.
Agenda Perencanaan Sprint: Contoh dengan Batas Waktu untuk Sprint 2 Minggu
Untuk sprint dua minggu, mulailah dengan sesi perencanaan selama dua jam, terutama jika daftar pekerjaan (backlog) telah disempurnakan. Siapkan waktu tambahan jika pekerjaan tersebut melibatkan ketergantungan yang kompleks atau beberapa keputusan yang memerlukan diskusi.
Anda dapat menyesuaikan contoh agenda ini dengan kebutuhan tim Anda.
| Waktu | Poin agenda | Siapa yang memimpin | Hasil yang diharapkan |
|---|---|---|---|
| 0:00–0:10 | Tinjau hasil sprint sebelumnya, pekerjaan yang belum selesai, dan tindakan yang dihasilkan dari retrospektif | Scrum Master memfasilitasi | Pemahaman bersama mengenai hal-hal yang perlu diperhatikan |
| 0:10–0:30 | Diskusikan tujuan sprint yang diusulkan oleh Product Owner dan sepakati hasil yang diinginkan | Seluruh Tim Scrum | Draf tujuan sprint yang dipahami oleh semua orang |
| 0:30–0:45 | Pastikan ketersediaan tim dan tinjau segala kendala kapasitas | Pengembang | Gambaran realistis mengenai kapasitas yang tersedia |
| 0:45–1:15 | Pilih item backlog yang mendukung tujuan tersebut | Pengembang, bersama Pemilik Produk | Pilihan pekerjaan yang diyakini tim dapat diselesaikan |
| 1:15–1:45 | Uraikan item yang telah dipilih dan diskusikan pendekatan pengiriman | Pengembang | Rencana awal untuk menyelesaikan pekerjaan |
| 1:45–2:00 | Tinjau ketergantungan, periksa tingkat keyakinan, dan tetapkan tujuan sprint secara final | Seluruh Tim Scrum | Sasaran sprint yang telah disepakati dan daftar pekerjaan sprint yang siap digunakan oleh tim |
Sebelum mengakhiri sesi, Anda dapat menggunakan pemeriksaan tingkat keyakinan singkat seperti Fist of Five, di mana setiap orang menilai tingkat keyakinannya terhadap rencana tersebut dengan menunjukkan jumlah jari dari nol hingga lima. Jika ada yang memberikan skor rendah, tanyakan apa yang menjadi penyebab kekhawatirannya. Hal ini dapat mengungkap ketergantungan yang belum terselesaikan, perkiraan yang terlalu ambisius, atau persyaratan yang memerlukan pembahasan lebih lanjut.
Tujuannya adalah untuk mengidentifikasi masalah selagi masih ada waktu untuk menyesuaikan rencana.
Cara Melakukan Perencanaan Sprint dalam 6 Langkah
Setelah Anda menyiapkan daftar pekerjaan (backlog) dan memastikan siapa saja yang akan hadir, mulailah sesi perencanaan. Tujuan di sini adalah membantu tim mengubah prioritas dan kapasitas yang tersedia menjadi rencana yang mereka yakini dapat diselesaikan.
Langkah 1: Tinjau pekerjaan sebelumnya dan sepakati tujuan sprint
Mulailah dengan melihat sekilas apa yang telah diselesaikan, apa yang masih belum selesai, dan apakah ada tindakan retrospektif yang seharusnya memengaruhi sprint berikutnya. Fokuslah pada hal-hal yang dapat mengubah prioritas atau pendekatan tim, daripada mengulangi seluruh tinjauan sprint.
Kemudian, mintalah Product Owner untuk memperkenalkan tujuan sprint yang diusulkan dan menjelaskan bagaimana tujuan tersebut mendukung Tujuan Produk yang lebih luas. Berikan ruang bagi para pengembang untuk mempertanyakan cakupannya, mengemukakan ketergantungan, dan mengusulkan penyesuaian.
Misalnya, jika tujuannya adalah memungkinkan pelanggan menyelesaikan proses checkout tanpa harus menghubungi tim penjualan, sepakati seperti apa bentuk checkout yang berhasil. Apakah proses tersebut mencakup konfirmasi pembayaran dan penanganan kesalahan? Apakah pengiriman tanda terima otomatis menjadi hal yang esensial untuk rilis pertama?
Diskusi-diskusi ini membantu Anda mendefinisikan hasil yang dapat dicapai oleh tim. Rumusan tujuan mungkin berubah seiring pemilihan item backlog, tetapi semua orang harus menyetujui tujuan akhir sebelum perencanaan berakhir.
Langkah 2: Hitung kapasitas yang tersedia dari tim
Sebelum memilih pekerjaan, tentukan berapa banyak waktu yang secara realistis dapat dialokasikan oleh para pengembang Anda untuk sprint tersebut.
Mulailah dengan jumlah hari kerja dan ketersediaan yang diharapkan dari setiap orang. Kemudian pertimbangkan cuti yang direncanakan, acara Scrum, tanggung jawab pendukung, dan komitmen lain yang sudah diketahui. Jika seorang pengembang menghabiskan setengah minggu mereka menangani masalah produksi, jam-jam tersebut sudah terikat dan tidak tersedia untuk pekerjaan sprint yang direncanakan.
Perhitungan sederhana adalah: Kapasitas yang tersedia = Total jam kerja − Komitmen yang sudah diketahui
Misalnya, seorang pengembang dengan 80 jam kerja selama dua minggu mungkin memiliki 8 jam cuti, 10 jam rapat, dan 12 jam tugas dukungan. Hal ini menyisakan 50 jam sebelum memperhitungkan ketidakpastian tambahan apa pun.
Bandingkan angka ini dengan kinerja tim di masa lalu. Velocity menunjukkan seberapa banyak pekerjaan yang telah diselesaikan tim pada sprint sebelumnya, sedangkan kapasitas mencerminkan waktu yang tersedia untuk sprint ini.
Tips Pro: Jika Anda menggunakan jam sebagai satuan untuk perencanaan kapasitas, pisahkanlah dari story points. Keduanya mengukur hal yang berbeda, dan tidak ada konversi universal di antara keduanya.
Langkah 3: Menilai kembali pekerjaan yang belum selesai dari sprint sebelumnya
Item backlog yang belum selesai perlu ditinjau kembali sebelum Anda menambahkannya ke sprint baru. Sebuah item yang penting dua minggu lalu mungkin telah berubah prioritasnya, atau tim mungkin telah memperoleh wawasan baru yang memengaruhi jumlah pekerjaan yang tersisa.
Tinjau setiap item bersama Product Owner dan pertimbangkan:
- Relevansi: Apakah hal ini masih mendukung tujuan sprint yang diusulkan atau prioritas produk penting lainnya?
- Upaya yang tersisa: Berapa banyak pekerjaan yang masih tersisa setelah sebagian dari item tersebut telah diselesaikan?
- Ketergantungan: Adakah hal yang menghalangi tim untuk membuat kemajuan?
- Prioritas: Apakah item ini harus didahulukan daripada item backlog yang baru disempurnakan?
Untuk pekerjaan yang masih termasuk dalam sprint, gunakan sisa upaya untuk menilai seberapa besar kapasitas yang dibutuhkan. Sebuah item yang setengah selesai mungkin memerlukan lebih sedikit pekerjaan daripada perkiraan awalnya, tetapi tetap dianggap belum selesai hingga memenuhi Definisi Selesai.
Langkah 4: Pilih item backlog yang mendukung tujuan tersebut
Dengan pemahaman yang jelas mengenai kapasitas dan pekerjaan yang masih tertunda, para pengembang dapat memilih item backlog produk yang mereka yakini dapat diselesaikan.
Mulailah dengan item yang secara langsung mendukung tujuan sprint. Diskusikan kriteria penerimaannya, ketergantungan teknis, dan ketidakpastian apa pun yang dapat memengaruhi pengiriman. Jika suatu item terlalu besar atau tidak jelas, pertimbangkan untuk membaginya menjadi bagian-bagian yang lebih kecil yang dapat memberikan nilai dalam sprint tersebut.
Anda mungkin juga memiliki ruang untuk pemeliharaan atau prioritas produk lainnya, tetapi pastikan apakah mengambil pekerjaan tersebut dapat membahayakan tujuan utama.
Berapa banyak kapasitas yang harus Anda sisihkan?
Merencanakan hanya 80% dari kapasitas yang tersedia dapat menjadi titik awal yang wajar bagi tim yang secara rutin menangani pekerjaan dukungan yang tidak terduga, tetapi Scrum tidak menetapkan persentase tetap.
Jika tim Anda sering mengalami gangguan, Anda dapat menyisihkan 10–20% dari kapasitas yang telah disesuaikan dan membandingkan alokasi tersebut dengan kebutuhan selama sprint sebelumnya. Tim dengan beban kerja yang stabil dan sedikit gangguan mungkin membutuhkan alokasi yang lebih sedikit. Sebaliknya, tim yang mendukung layanan aktif dengan insiden yang sering terjadi mungkin membutuhkan alokasi yang lebih besar.
Hindari menghitung komitmen yang sama dua kali. Jika jam dukungan yang dijadwalkan sudah dikurangkan pada Langkah 2, buffer tambahan harus mencakup ketidakpastian di luar beban kerja yang sudah diketahui tersebut. Gunakan kapasitas yang dihasilkan sebagai panduan untuk diskusi, bukan sebagai target yang harus dicapai.
Ingat: Sprint dengan kapasitas yang tersisa tidak selalu berarti perencanaan yang kurang matang. Jika Anda telah memilih pekerjaan yang cukup untuk mencapai tujuan sprint, mengisi sisa waktu dengan tugas-tugas yang tidak terkait dapat menimbulkan prioritas yang saling bertentangan. Terkadang perkiraan yang lebih kecil lebih realistis, terutama ketika pekerjaan yang dipilih memiliki ketidakpastian yang signifikan.
Langkah 5: Pisahkan pekerjaan dan periksa ketergantungan
Setelah item backlog dipilih, para pengembang dapat merencanakan cara mereka akan menyelesaikannya. Hal ini dapat melibatkan pemecahan item yang lebih besar menjadi tugas-tugas pengembangan, pengujian, integrasi, dan tinjauan.
Perhatikan dengan cermat urutan pekerjaan. Jika antarmuka checkout bergantung pada integrasi penyedia pembayaran, tim harus memahami kapan integrasi tersebut harus siap. Jika tim lain harus menyetujui perubahan keamanan, jelaskan bagaimana dan kapan keputusan tersebut akan diambil.
Rencanakan pekerjaan yang akan segera dilakukan secara lebih rinci, sementara tugas-tugas selanjutnya dibiarkan terbuka untuk dibahas lebih lanjut. Panduan Scrum menyarankan untuk memecah item yang dipilih menjadi item pekerjaan yang lebih kecil, biasanya berukuran satu hari atau kurang, tetapi para pengembanglah yang memutuskan cara mengatur dan mendistribusikan pekerjaan tersebut.
Pastikan rencana tersebut memperhitungkan Definisi Selesai (Definition of Done), termasuk pengujian dan pekerjaan integrasi yang esensial. Jika ada ketergantungan yang berpotensi menghambat pengiriman, tinjau kembali item yang dipilih atau sesuaikan pendekatan pengiriman sebelum meresmikan rencana.
Langkah 6: Menyempurnakan dan membagikan daftar tugas sprint
Catat tujuan sprint, item product backlog yang dipilih, dan rencana pengiriman awal di tempat yang dapat diakses dan diperbarui oleh tim. Secara keseluruhan, hal-hal ini harus memperjelas apa yang ingin dicapai oleh tim dan pekerjaan mana yang perlu ditangani selanjutnya.
Sebelum menutup rapat, pastikan bahwa tujuan tersebut telah disepakati dan berikan kesempatan kepada semua orang untuk menyampaikan kekhawatiran terkait perkiraan yang masih tersisa. Jika ada ketergantungan penting atau masalah kapasitas yang belum terselesaikan, diskusikan apa yang perlu diubah sebelum tim mulai bekerja.
Selama sprint, Daily Scrum memberi kesempatan kepada para pengembang untuk memeriksa kemajuan menuju tujuan dan menyesuaikan sprint backlog. Grafik burndown atau burnup dapat membantu menunjukkan perubahan dalam kemajuan, sementara tugas-tugas yang mendasarinya memberikan detail lebih lanjut. Jika informasi baru memengaruhi ruang lingkup yang telah dipilih, para pengembang dapat mendiskusikan penyesuaian dengan Product Owner tanpa membahayakan tujuan sprint.
Contoh Perencanaan Sprint: Sebuah Tim dengan 6 Pengembang
Mari kita lihat bagaimana keputusan-keputusan ini diterapkan dalam praktik.
Bayangkan Anda sedang merencanakan sprint dua minggu untuk produk penagihan B2B. Tim Anda terdiri dari enam pengembang dan memiliki tujuan sprint yang diusulkan: “Pelanggan baru dapat membayar dengan kartu saat checkout tanpa perlu menghubungi tim penjualan.”
Sebelum memilih item backlog, Anda perlu mengetahui berapa banyak waktu yang tersedia bagi tim. Untuk contoh ini, anggaplah setiap pengembang memiliki enam jam potensial untuk pekerjaan proyek yang terfokus per hari, sebelum dikurangi dengan acara Scrum yang direncanakan dan komitmen lainnya.
Inilah cara perhitungan kapasitas dilakukan selama 10 hari kerja:
| Perhitungan kapasitas | Jam |
|---|---|
| Kapasitas dasar: 6 pengembang × 10 hari × 6 jam | 360 |
| Cuti yang direncanakan: 1 pengembang tidak hadir selama 2 hari | −12 |
| Tugas piket: 1 pengembang dengan ketersediaan 50% | −30 |
| Acara Scrum: 8 jam per pengembang | −48 |
| Kapasitas yang tersedia | 270 |
| Sisihkan 20% untuk pekerjaan tak terduga | −54 |
| Kapasitas yang tersedia untuk pekerjaan yang direncanakan | 216 |
Anda kini memiliki 216 jam untuk pekerjaan yang direncanakan setelah menyisihkan cadangan 20% sebagai ilustrasi. Dalam praktiknya, Anda akan menentukan besaran cadangan tersebut berdasarkan seberapa banyak pekerjaan tak terduga yang mengganggu sprint-sprint sebelumnya.
Pilih pekerjaan yang mendukung tujuan sprint
Setelah kapasitas ditetapkan, para pengembang meninjau item backlog yang terkait dengan checkout bersama Product Owner.
Berikut adalah contoh ilustratif berdasarkan perkiraan upaya awal pada tingkat tugas:
| Item backlog | Perkiraan upaya |
|---|---|
| Buat formulir pembayaran dengan kartu | 48 jam |
| Integrasikan penyedia layanan pembayaran | 88 jam |
| Menangani pembayaran yang gagal dan kesalahan validasi | 50 jam |
| Tambahkan konfirmasi pembayaran dan pengiriman tanda terima | 24 jam |
| Total pekerjaan yang direncanakan | 210 jam |
Perkiraan ini menyisakan 6 jam dalam alokasi pekerjaan yang direncanakan, ditambah cadangan 54 jam untuk pekerjaan tak terduga. Tim juga memiliki perbaikan dasbor pelaporan dalam daftar pekerjaan produk. Meskipun hal ini berharga, hal tersebut tidak berkontribusi langsung terhadap tujuan penyelesaian. Pemilik Produk dan pengembang sepakat untuk menundanya ke sprint berikutnya.
Sesuaikan rencana tersebut jika terjadi perubahan
Pada hari keenam, penyedia layanan pembayaran memperkenalkan perubahan API yang menyebabkan sebagian integrasi tidak berfungsi. Para pengembang menyelidiki dan memperkirakan pekerjaan tambahan yang diperlukan.
Alih-alih melanjutkan urutan tugas semula, mereka mendiskusikan dampaknya dengan Product Owner. Jika perbaikan tersebut masih sesuai dengan kapasitas yang tersisa, mereka dapat memprioritaskannya dan menunda penataan tampilan tanda terima opsional atau tugas lain dengan prioritas lebih rendah. Konfirmasi pembayaran dan pekerjaan penting lainnya tetap harus memenuhi Definisi Selesai.
Jika perbaikan yang diperlukan lebih besar dari yang diperkirakan, mereka perlu mengevaluasi kembali cakupan yang tersisa dan apakah tujuan sprint masih dapat dicapai.
Tim mungkin menyelesaikan lebih sedikit item backlog daripada yang diperkirakan semula. Namun, jika pelanggan dapat menyelesaikan proses checkout sesuai rencana dan pekerjaan tersebut memenuhi Definisi Selesai, maka tujuan sprint telah tercapai.
Contoh tujuan sprint untuk tim lain
Anda dapat menerapkan pendekatan perencanaan yang sama untuk pekerjaan di luar pengembangan perangkat lunak, meskipun Scrum sendiri merupakan kerangka kerja khusus dengan tanggung jawab dan acara yang telah ditetapkan.
Misalnya, tim pemasaran mungkin menetapkan tujuan seperti “Menerbitkan halaman arahan webinar dan memungkinkan pengunjung mendaftar tanpa bantuan manual.” Tim operasional dapat menargetkan “Memastikan setiap karyawan dalam kelompok onboarding berikutnya memiliki peralatan dan akses sistem yang diperlukan pada hari pertama mereka.”
Kedua tujuan tersebut menggambarkan hasil yang dapat memandu keputusan tim sepanjang sprint. Item backlog dan rencana pengiriman mungkin berbeda-beda, tetapi tim tetap perlu mempertimbangkan kapasitasnya dan menyepakati seperti apa bentuk pengiriman yang sukses.
Kesalahan Umum dalam Perencanaan Sprint dan Cara Mengatasinya
Perencanaan sprint dapat menemui kendala jika tim menggunakan story points untuk menilai kinerja individu, membawa item backlog yang tidak jelas ke dalam rapat, membagikan pekerjaan secara terlalu kaku, atau mengabaikan persyaratan pengujian dan ketergantungan eksternal.
Beberapa penyesuaian dapat membantu Anda mengidentifikasi masalah-masalah ini sebelum memengaruhi proses pengiriman.
| Kesalahan | Mengapa hal ini menimbulkan masalah | Cara memperbaikinya |
| Menggunakan story points untuk mengukur kinerja individu | Membandingkan pengembang berdasarkan poin yang telah diselesaikan dapat mendorong perkiraan yang terlalu tinggi atau penghindaran terhadap pekerjaan yang kompleks. | Pastikan poin cerita tetap berfokus pada perkiraan tingkat tim. Tinjau pekerjaan yang telah diselesaikan di beberapa sprint dan diskusikan perubahan perkiraan selama sesi penyempurnaan. Nilai kinerja individu melalui kualitas kode, kolaborasi, dan hasil yang dicapai. |
| Membawa item backlog yang tidak jelas ke dalam perencanaan | Kriteria penerimaan yang terlewat atau pertanyaan teknis yang belum terjawab dapat mengubah sesi perencanaan menjadi diskusi tentang apa yang akan dibangun, sehingga menyisakan lebih sedikit waktu untuk merencanakan pengiriman. | Selesaikan pertanyaan selama penyempurnaan backlog agar pengembang dapat membuat perkiraan yang masuk akal. Jika masih ada ketidakpastian, pertimbangkan bagian pekerjaan yang lebih kecil dan lebih mudah dipahami. Usahakan kejelasan yang cukup untuk mengambil keputusan, bukan spesifikasi yang sempurna. |
| Menugaskan setiap tugas kepada seseorang sebelum pekerjaan dimulai | Penugasan yang tetap membuat proses adaptasi menjadi lebih sulit ketika prioritas berubah atau ketika seorang pengembang menyelesaikan tugasnya lebih awal sementara pengembang lain membutuhkan bantuan. | Biarkan para pengembang mengatur pekerjaan. Sepakati tanggung jawab langsung dan masukan dari spesialis, lalu izinkan rekan tim untuk mengambil alih, bekerja berpasangan, atau mendistribusikan ulang tugas selama sprint. Pastikan pekerjaan tetap terlihat oleh seluruh tim. |
| Membiarkan ketergantungan eksternal tidak terselesaikan | Ketiadaan kredensial API, tinjauan keamanan, atau hasil kerja tim lain dapat membuat tim harus menunggu pekerjaan yang tidak dapat mereka kendalikan. | Sebelum menyelesaikan daftar tugas sprint, identifikasi masukan yang diperlukan, siapa yang akan mengoordinasikannya, dan kapan diharapkan tersedia. Jika ketergantungan kritis masih belum pasti, pertimbangkan item alternatif atau cakupan yang lebih kecil yang dapat diselesaikan tim secara mandiri. |
Jika masalah yang sama terus muncul di beberapa sprint, bawa masalah tersebut ke sesi retrospektif sprint dan sepakati perubahan yang dapat Anda uji selama sprint berikutnya. Template retrospektif sprint ini dapat membantu Anda mencatat pengamatan dan tindakan tindak lanjut.
Di akhir sprint, gunakan rapat tinjauan sprint untuk memeriksa hasil kerja yang telah diselesaikan bersama para pemangku kepentingan dan mendiskusikan apa yang harus ditangani tim selanjutnya.
Cara Melakukan Perencanaan Sprint di ClickUp
Perencanaan sprint membutuhkan lebih banyak usaha jika tugas, perkiraan kapasitas, dan keputusan perencanaan tersebar di berbagai alat. ClickUp menyatukan informasi tersebut, sehingga tim dapat meninjau pekerjaan bersamaan dengan kapasitas dan mengevaluasi kembali keputusan perencanaan saat rencana berubah.
Mulailah dengan Template Perencanaan Sprint Agile ClickUp. Tampilan backlog, status pengembangan, dan sumber daya di dalamnya membantu Anda meninjau pekerjaan yang akan datang dan mempersiapkan diri untuk diskusi perencanaan.
Berikut cara mengambil keputusan-keputusan utama:
- Buat pekerjaan yang akan datang lebih mudah dievaluasi: Simpan persyaratan, kriteria penerimaan, prioritas, dan ketergantungan dalam daftar backlog Tugas ClickUp. Detail-detail ini membantu pengembang mendiskusikan cakupan dan memperkirakan upaya yang diperlukan sebelum memilih pekerjaan. Tambahkan tugas-tugas yang telah dipilih ke dalam sprint setelah tim menyetujui rencana tersebut
- Tentukan jendela perencanaan yang konsisten: Konfigurasikan durasi sprint dan tanggal mulai di ClickUp Sprints. Gunakan Sprint Points atau Perkiraan Waktu untuk menilai upaya yang diperlukan dan membantu tim menentukan seberapa banyak pekerjaan yang dapat mereka tangani
- Periksa apakah pekerjaan sesuai: Bandingkan pekerjaan yang ditugaskan dengan kapasitas masing-masing orang di Tampilan Beban Kerja ClickUp. Tinjau beban kerja yang tidak merata dan diskusikan perubahan apa pun sebelum menyelesaikan perkiraan
- Pastikan agenda dan keputusan tetap relevan dengan pekerjaan: Gunakan ClickUp Docs untuk agenda berwaktu, tujuan sprint yang diusulkan, dan tautan ke tugas-tugas yang relevan. Catat keputusan terkait ruang lingkup dan pertanyaan yang belum terselesaikan selama sesi agar tim dapat meninjaunya kembali seiring berjalannya pekerjaan
- Catat diskusi perencanaan: ClickUp AI Notetaker dapat merekam rapat di Zoom, Google Meet, Microsoft Teams, atau SyncUps, serta menyimpan ringkasan, keputusan penting, dan tindakan yang harus dilakukan dalam dokumen. Tinjau catatan tersebut, lalu perbarui tugas-tugas sprint dengan tindak lanjut yang telah disepakati
- Gunakan data kemajuan untuk memandu diskusi: Tambahkan kartu Sprint Burndown atau Burnup ke Dasbor ClickUp untuk meninjau pekerjaan yang telah diselesaikan dan upaya yang masih tersisa. Jika kemajuan berbeda dari rencana, tinjau tugas-tugas terkait untuk mengetahui adanya penundaan atau perubahan ruang lingkup yang perlu diperhatikan
Sebelum sesi perencanaan berikutnya, tanyakan kepada Brain², “Ketergantungan apa saja yang belum terselesaikan yang muncul dalam sesi perencanaan sprint terakhir kita?” Brain dapat mengambil konteks dari catatan rapat yang telah direkam. Periksa detail tersebut dengan tugas-tugas saat ini sebelum menggunakannya sebagai dasar untuk perkiraan berikutnya.
Harga ClickUp
Cocok untuk: Tim Scrum yang mengelola beberapa sprint, ketergantungan bersama, dan beban kerja yang berubah-ubah yang memerlukan pengelolaan backlog, perencanaan kapasitas, dan pelaporan kemajuan dalam satu ruang kerja. Ini juga cocok untuk tim yang mengoordinasikan pekerjaan sprint dengan proyek produk atau bisnis yang lebih luas.
Lewati jika: Tim Anda hanya membutuhkan papan Scrum dasar dengan backlog kecil dan pelaporan minimal. Fleksibilitas ClickUp disertai dengan keputusan pengaturan seputar pengaturan sprint, tampilan, dan bidang. Beberapa fitur pelaporan dan otomatisasi sprint tingkat lanjut juga memerlukan paket berlangganan tingkat atas, yang mungkin tidak diperlukan untuk alur kerja yang sederhana.
Seberapa Banyak yang Harus Anda Rencanakan Sebelum Sprint Dimulai?
Sesi perencanaan sprint harus memberikan kejelasan yang cukup kepada tim agar dapat segera memulai pekerjaan.
Agenda berwaktu dan contoh perhitungan kapasitas di atas dapat dijadikan titik awal. Sesuaikan keduanya dengan beban kerja tim, lalu bandingkan perkiraan tersebut dengan pekerjaan yang telah diselesaikan dan gangguan yang terjadi untuk meningkatkan perencanaan berikutnya.
Di ClickUp, Anda dapat menghubungkan catatan perencanaan ke tugas-tugas sprint dan memperbarui daftar tugas sprint (sprint backlog) seiring perubahan pekerjaan. Tim dapat merujuk kembali ke rencana yang telah disepakati saat memutuskan apa yang perlu disesuaikan.
Pertanyaan yang Sering Diajukan tentang Perencanaan Sprint
Apa perbedaan antara perencanaan sprint dan perencanaan rilis?
Perencanaan sprint berfokus pada apa yang ingin dicapai tim Anda selama satu sprint dan bagaimana tim akan menyelesaikan pekerjaan tersebut. Perencanaan rilis mempertimbangkan jangka waktu yang lebih panjang, seperti fitur-fitur apa saja yang dapat tersedia dalam beberapa sprint dan kapan pengguna mungkin menerimanya. Perkiraan rilis dapat berubah seiring tim memperoleh informasi lebih lanjut, sementara setiap tujuan sprint menjadi panduan bagi pekerjaan dalam sprint tersebut.
Apakah Anda memerlukan Definisi Kesiapan untuk perencanaan sprint?
Tidak. Scrum tidak mengharuskan adanya Definisi Siap yang formal. Beberapa tim menggunakannya untuk menetapkan ekspektasi bersama terkait item backlog sebelum pemilihan, seperti persyaratan yang jelas, cakupan yang dapat dikelola, dan ketergantungan yang diketahui. Pastikan kriteria ini tetap ringan agar dapat mendukung diskusi tanpa menghalangi tim untuk menyempurnakan item saat diperlukan.
Apakah sprint dapat dibatalkan setelah perencanaan?
Ya. Hanya Pemilik Produk yang dapat membatalkan sprint, dan pembatalan menjadi opsi ketika tujuan sprint menjadi tidak relevan lagi, mungkin karena prioritas bisnis atau kondisi pasar telah berubah secara signifikan. Tugas yang sulit atau perkiraan yang tidak akurat saja tidak selalu menjadi alasan yang cukup untuk pembatalan.
Apa perbedaan antara sprint dan agile?
Agile adalah pendekatan yang lebih luas dalam mengelola pekerjaan berdasarkan nilai-nilai dan prinsip-prinsip Manifesto Agile. Sprint adalah periode tetap selama satu bulan atau kurang dalam kerangka kerja Scrum, di mana tim bekerja untuk mencapai tujuan sprint dan menghasilkan peningkatan yang dapat digunakan. Anda dapat mengikuti prinsip-prinsip Agile tanpa menggunakan sprint. Kanban, misalnya, mendukung aliran pekerjaan yang berkelanjutan tanpa memerlukan iterasi dengan durasi tetap.
Apakah satu sprint dapat memiliki beberapa tujuan sprint?
Scrum mendefinisikan satu tujuan sprint sebagai tujuan tunggal dari sprint tersebut. Anda dapat memilih item backlog yang mendukung prioritas lain, selama hal tersebut tidak membahayakan tujuan tersebut. Jika tim Anda secara rutin membutuhkan beberapa tujuan yang tidak saling terkait, diskusikan apakah pekerjaan tersebut mendukung hasil bersama yang lebih luas atau apakah Anda perlu menyelesaikan prioritas yang saling bertentangan sebelum melakukan perencanaan.
Apakah Anda perlu memperkirakan bug dalam poin cerita selama perencanaan sprint?
Story points bersifat opsional dalam Scrum, termasuk untuk bug. Tim yang melakukan estimasi bug harus menyepakati kapan dan mengapa melakukannya. Cacat yang sudah diketahui dapat dievaluasi selama perencanaan, sementara bug yang ditemukan selama pengembangan mungkin termasuk dalam pekerjaan yang sudah diperlukan untuk memenuhi Definisi Selesai. Hindari menghitung upaya yang sama dua kali.