Planning Poker merupakan teknik estimasi kolaboratif yang membantu tim Agile membandingkan kompleksitas, usaha, risiko, dan ketidakpastian sebuah pekerjaan sebelum pekerjaan tersebut dimasukkan ke dalam sprint.
Dalam Planning Poker, setiap anggota tim memilih kartu estimasi secara mandiri. Seluruh kartu dibuka secara bersamaan. Ketika nilainya berbeda, peserta mendiskusikan asumsi masing-masing lalu melakukan estimasi ulang sampai tim memiliki pemahaman yang lebih seragam.
Apa Itu Planning Poker?
Planning Poker, yang juga sering disebut Scrum Poker, adalah metode estimasi berbasis konsensus. Metode ini digunakan untuk membantu tim memperkirakan ukuran relatif sebuah user story, tugas, atau pekerjaan teknis.
Dalam prosesnya, anggota tim tidak langsung menyebutkan estimasi secara terbuka. Setiap orang memilih nilai secara mandiri, kemudian seluruh nilai ditampilkan dalam waktu yang sama. Pendekatan ini mengurangi risiko peserta mengikuti pendapat orang yang pertama berbicara atau anggota yang dianggap paling senior.
Planning Poker bukan permainan untuk menentukan siapa yang memberikan jawaban paling tepat. Perbedaan estimasi justru menjadi bagian terpenting dari proses. Perbedaan tersebut sering mengungkapkan asumsi tersembunyi, kebutuhan pengujian, risiko keamanan, dependensi teknis, atau ruang lingkup yang belum dijelaskan dengan baik.
Sebagai contoh, seorang developer mungkin menganggap sebuah perubahan hanya memerlukan penyesuaian antarmuka. Sementara itu, anggota QA melihat adanya kebutuhan pengujian regresi pada beberapa perangkat. Perbedaan perspektif tersebut membuat estimasi tim menjadi lebih lengkap.
Mengapa Tim Menggunakan Planning Poker?
Tujuan utama Planning Poker bukan menghasilkan angka yang terlihat presisi. Tujuannya adalah membantu anggota tim membangun pemahaman yang sama mengenai pekerjaan yang akan dilakukan.
Sesi estimasi yang baik dapat membantu tim menemukan ketidakjelasan sebelum pekerjaan masuk ke tahap implementasi. Hal ini lebih efisien dibandingkan menemukan masalah tersebut ketika sprint sudah berjalan.
Mengurangi pengaruh pendapat pertama
Ketika estimasi disampaikan secara berurutan, angka pertama dapat menjadi jangkar bagi peserta lain. Anggota tim mungkin mengubah perkiraannya agar tidak terlihat terlalu berbeda.
Planning Poker mengurangi efek tersebut karena setiap orang menentukan pilihan sebelum melihat pilihan peserta lain.
Membuka diskusi lintas peran
Developer, QA, designer, analyst, dan anggota tim lainnya dapat melihat pekerjaan dari sudut pandang berbeda. Diskusi tersebut membantu tim memperhitungkan seluruh aktivitas yang diperlukan untuk memenuhi definisi selesai.
Membantu pemecahan pekerjaan besar
Nilai estimasi yang sangat besar sering menjadi tanda bahwa sebuah user story terlalu luas atau terlalu tidak pasti. Tim dapat memecahnya menjadi beberapa bagian yang lebih kecil dan lebih mudah divalidasi.
Perlu diingat: Planning Poker tidak menjamin seluruh estimasi akan selalu akurat. Teknik ini membantu tim memperbaiki kualitas percakapan dan mengidentifikasi ketidakpastian lebih awal.
Persiapan Sebelum Sesi Estimasi
Planning Poker akan berjalan lebih efektif apabila pekerjaan yang dibahas sudah memiliki konteks yang cukup. Tim tidak harus mengetahui seluruh detail, tetapi tujuan dan batas pekerjaannya perlu dapat dipahami.
User story harus mempunyai tujuan yang jelas
Tim perlu memahami siapa pengguna yang menerima manfaat, masalah apa yang diselesaikan, dan hasil seperti apa yang diharapkan. Judul tugas yang terlalu umum seperti “perbaiki halaman pembayaran” belum cukup untuk menghasilkan estimasi yang berguna.
Sertakan kriteria penerimaan
Kriteria penerimaan menjelaskan kondisi yang harus terpenuhi agar pekerjaan dapat dianggap selesai. Kriteria ini membantu developer dan QA memahami batas pengujian serta perilaku sistem yang diharapkan.
Identifikasi dependensi utama
Ketergantungan terhadap API, vendor, sistem lama, persetujuan legal, desain, atau tim lain dapat meningkatkan risiko pekerjaan. Dependensi yang diketahui perlu disebutkan sebelum voting dimulai.
Gunakan pekerjaan referensi
Tim dapat memilih satu atau dua pekerjaan lama sebagai pembanding. Misalnya, pekerjaan sederhana yang sudah dipahami bersama diberi nilai dua atau tiga. Pekerjaan baru kemudian dibandingkan dengan referensi tersebut.
- Tujuan user story dapat dijelaskan secara singkat.
- Kriteria penerimaan sudah tersedia.
- Tim mengetahui dependensi utama.
- Kebutuhan desain dan pengujian telah dibahas.
- Pekerjaan referensi tersedia sebagai pembanding.
Cara Menjalankan Planning Poker
Planning Poker dapat dilakukan dalam pertemuan tatap muka maupun jarak jauh. Tim hanya memerlukan kumpulan kartu fisik atau alat digital yang dapat menyembunyikan pilihan peserta sampai voting selesai.
Product Owner menjelaskan pekerjaan
Product Owner atau pihak yang memahami kebutuhan menjelaskan tujuan, konteks, ruang lingkup, serta kriteria penerimaan user story.
Peserta mengajukan pertanyaan
Anggota tim membahas aspek teknis, pengalaman pengguna, pengujian, keamanan, data, serta dependensi yang mungkin memengaruhi ukuran pekerjaan.
Setiap peserta memilih kartu
Peserta memilih nilai secara mandiri. Pilihan tidak boleh terlihat oleh peserta lain sebelum seluruh anggota selesai memberikan estimasi.
Semua kartu dibuka bersamaan
Fasilitator menampilkan seluruh pilihan. Apabila nilainya sama atau berdekatan, tim dapat menyepakati nilai akhir dengan cepat.
Bahas estimasi terendah dan tertinggi
Peserta dengan pilihan paling rendah dan paling tinggi menjelaskan asumsi mereka. Fokus diskusi berada pada alasan di balik nilai, bukan pada orang yang memilihnya.
Lakukan voting ulang
Setelah mendapatkan informasi tambahan, peserta memilih kembali. Sesi dapat diulang sampai tim memiliki pemahaman yang cukup untuk menentukan estimasi.
Sesi tidak harus menghasilkan suara bulat. Tim dapat menyepakati nilai yang masuk akal setelah asumsi dan risiko utama dipahami bersama.
Memahami Story Point dan Skala Fibonacci
Story point adalah ukuran relatif yang digunakan untuk membandingkan pekerjaan. Angka tersebut umumnya mencerminkan gabungan antara usaha, kompleksitas, risiko, dan ketidakpastian.
Story point bukan ukuran waktu. Pekerjaan bernilai delapan poin tidak otomatis membutuhkan waktu dua kali lebih lama daripada pekerjaan empat poin. Nilainya hanya menunjukkan bahwa tim menilai pekerjaan tersebut secara relatif lebih besar atau lebih tidak pasti.
Banyak tim menggunakan skala yang menyerupai deret Fibonacci:
Jarak antarangka menjadi semakin besar karena ketidakpastian juga meningkat ketika ukuran pekerjaan membesar. Sulit membedakan secara bermakna antara pekerjaan berukuran 20 dan 21, sehingga skala tidak perlu menggunakan setiap angka secara berurutan.
Apa yang dipertimbangkan saat memilih nilai?
- Kompleksitas perubahan kode atau arsitektur.
- Jumlah komponen yang harus diubah.
- Kebutuhan pengujian dan regresi.
- Ketergantungan pada sistem atau tim lain.
- Risiko keamanan dan perlindungan data.
- Ketidakjelasan kebutuhan atau desain.
- Tingkat pengalaman tim terhadap teknologi terkait.
Hindari konversi tetap seperti satu story point sama dengan satu hari. Konversi semacam itu dapat menghilangkan sifat relatif story point dan mendorong tim memperdebatkan durasi alih-alih membahas kompleksitas serta risiko.
Peran Peserta dalam Planning Poker
Tidak semua peserta memiliki tanggung jawab yang sama. Namun setiap perspektif yang relevan perlu mendapatkan kesempatan untuk didengar.
Menjelaskan tujuan bisnis, kebutuhan pengguna, prioritas, dan kriteria penerimaan pekerjaan.
Menilai kompleksitas implementasi, perubahan arsitektur, integrasi, dan risiko teknis.
Mengidentifikasi skenario pengujian, dampak regresi, kebutuhan data, dan variasi perangkat.
Menjelaskan kebutuhan desain, perilaku antarmuka, kondisi kosong, kesalahan, dan aksesibilitas.
Memfasilitasi proses, menjaga diskusi tetap fokus, dan memastikan setiap peserta mendapatkan ruang berbicara.
Security engineer, data analyst, legal, atau anggota lain dapat dilibatkan apabila pekerjaannya membutuhkan pengetahuan khusus.
Contoh Sederhana Sesi Planning Poker
User story: menambahkan fitur lupa kata sandi
Product Owner menjelaskan bahwa pengguna perlu dapat meminta tautan pengaturan ulang kata sandi melalui email. Tautan harus memiliki masa berlaku dan tidak dapat digunakan lebih dari satu kali.
Setelah diskusi awal, lima anggota tim memilih kartu berikut:
Peserta yang memilih nilai tiga menganggap tim dapat menggunakan sistem email yang sudah tersedia. Peserta yang memilih nilai tiga belas menjelaskan bahwa sistem belum memiliki mekanisme token satu kali pakai, pencatatan audit, pembatasan permintaan, dan pengujian terhadap penyalahgunaan akun.
Setelah risiko keamanan dibahas, tim memperjelas kriteria penerimaan dan melakukan voting kedua.
Tim akhirnya memilih delapan poin. Nilai akhir bukan bagian paling penting dari contoh tersebut. Nilai terbesar muncul karena ada risiko keamanan yang sebelumnya belum dipahami semua peserta.
Metrik Sprint yang Perlu Dipantau
Setelah menggunakan Planning Poker, tim dapat membandingkan estimasi dengan pola hasil sprint. Namun satu metrik tidak cukup untuk menggambarkan kesehatan proses pengembangan.
Metrik sebaiknya dibaca sebagai tren dalam beberapa sprint dan selalu disertai konteks. Pergantian anggota, pekerjaan darurat, cuti, perubahan prioritas, atau gangguan sistem dapat memengaruhi hasil sprint.
Jumlah story point yang memenuhi definisi selesai dalam satu sprint.
Perbandingan antara pekerjaan yang direncanakan dengan pekerjaan yang benar- benar selesai.
Waktu sejak pekerjaan mulai dikerjakan sampai mencapai status selesai.
Usia pekerjaan yang masih berlangsung dan belum mencapai status selesai.
Pekerjaan yang tidak selesai dan harus dipindahkan ke sprint berikutnya.
Perubahan jumlah cacat, insiden, atau masalah kualitas dari waktu ke waktu.
| Metrik | Berguna untuk | Jangan digunakan untuk |
|---|---|---|
| Velocity | Membantu memperkirakan kapasitas tim dalam sprint berikutnya. | Membandingkan produktivitas individu atau tim berbeda. |
| Predictability | Menilai kestabilan perencanaan dan perubahan ruang lingkup. | Memaksa seluruh sprint selalu mencapai seratus persen. |
| Cycle time | Menemukan hambatan dalam aliran pekerjaan. | Menilai kualitas hasil tanpa informasi pendukung. |
| Defect trend | Mengamati perubahan kualitas produk dari waktu ke waktu. | Menyalahkan anggota tim tertentu atas seluruh masalah. |
Mengapa velocity tidak boleh dijadikan target?
Ketika velocity dijadikan target yang harus terus meningkat, tim dapat terdorong menaikkan nilai story point tanpa peningkatan hasil yang nyata. Angka terlihat membaik, tetapi kemampuan pengiriman produk belum tentu berubah.
Velocity lebih berguna sebagai alat perencanaan internal. Tim dapat melihat rentang kapasitas historis dan menggunakannya untuk menghindari komitmen sprint yang terlalu besar.
Kesalahan Umum dalam Planning Poker
Mengambil nilai rata-rata tanpa diskusi
Ketika satu peserta memilih tiga dan peserta lain memilih tiga belas, mengambil angka rata-rata akan menghilangkan informasi penting. Tim perlu memahami mengapa selisih estimasi tersebut terjadi.
Memulai voting sebelum kebutuhan dipahami
Estimasi yang diberikan terhadap user story yang belum jelas biasanya hanya menghasilkan ketepatan semu. Luangkan waktu untuk menjelaskan tujuan dan kriteria penerimaan terlebih dahulu.
Membiarkan peserta senior mendominasi
Pengalaman anggota senior tetap berharga, tetapi perspektif tersebut tidak boleh otomatis menggantikan masukan anggota lain. QA atau developer yang baru bergabung mungkin melihat risiko yang tidak diperhatikan peserta lain.
Membandingkan story point antar tim
Setiap tim mempunyai konteks, definisi selesai, pengalaman, teknologi, dan cara kalibrasi yang berbeda. Tim A yang menyelesaikan 40 poin tidak otomatis lebih produktif daripada Tim B yang menyelesaikan 25 poin.
Mengestimasi pekerjaan yang terlalu besar
Pekerjaan dengan estimasi sangat tinggi sebaiknya ditinjau kembali. Tim dapat memecahnya berdasarkan alur pengguna, tahapan implementasi, aturan bisnis, atau bagian sistem.
Mengabaikan pekerjaan noncoding
Sebuah fitur tidak selesai hanya karena kode sudah ditulis. Estimasi juga perlu mempertimbangkan desain, pengujian, dokumentasi, observability, keamanan, migrasi data, dan proses peluncuran.
Planning Poker bukan alat evaluasi karyawan. Menggunakannya untuk mengukur produktivitas individu dapat mendorong manipulasi angka dan mengurangi keterbukaan dalam diskusi.
Planning Poker untuk Tim Jarak Jauh
Tim jarak jauh dapat menjalankan proses yang sama menggunakan kartu digital atau fitur voting tersembunyi. Hal terpenting adalah memastikan pilihan peserta tidak terlihat sebelum semua orang selesai memilih.
Fasilitator sebaiknya memberikan waktu hening sebelum voting. Waktu tersebut memungkinkan peserta membaca kriteria penerimaan dan mempertimbangkan risiko tanpa terburu-buru mengikuti arah pembicaraan.
Untuk tim yang berada di zona waktu berbeda, estimasi juga dapat dilakukan secara asinkron. Namun setiap peserta tetap perlu mencatat alasan ketika memilih nilai yang jauh lebih tinggi atau lebih rendah daripada peserta lain.
- Bagikan user story sebelum sesi dimulai.
- Gunakan alat yang menyembunyikan suara.
- Batasi diskusi agar tetap berfokus pada pekerjaan.
- Catat asumsi penting setelah estimasi selesai.
- Jadwalkan diskusi tambahan apabila perbedaan terlalu besar.
Pertanyaan Umum tentang Planning Poker
Apa itu Planning Poker?
Planning Poker adalah teknik estimasi kolaboratif yang digunakan tim Agile untuk memperkirakan ukuran relatif, kompleksitas, risiko, dan ketidakpastian sebuah pekerjaan.
Apakah Planning Poker hanya untuk tim Scrum?
Tidak. Teknik ini dapat digunakan oleh tim Kanban, tim produk, tim pengembangan perangkat lunak, dan kelompok lain yang membutuhkan estimasi kolaboratif.
Apakah story point sama dengan jam kerja?
Tidak. Story point merupakan ukuran relatif yang mempertimbangkan usaha, kompleksitas, risiko, dan ketidakpastian. Story point tidak sebaiknya dikonversi secara tetap menjadi jam.
Siapa yang mengikuti sesi Planning Poker?
Sesi biasanya melibatkan orang yang akan mengembangkan, menguji, merancang, atau meninjau pekerjaan tersebut. Product Owner menjelaskan tujuan dan kriteria penerimaannya.
Bagaimana jika semua peserta memilih angka berbeda?
Minta peserta dengan estimasi paling rendah dan paling tinggi menjelaskan asumsi mereka. Setelah informasi tambahan dibahas, lakukan voting ulang.
Apakah sprint velocity harus selalu meningkat?
Tidak. Velocity digunakan untuk membantu perencanaan kapasitas tim, bukan sebagai target produktivitas yang harus terus meningkat.
Berapa lama sesi Planning Poker?
Durasi bergantung pada jumlah dan kompleksitas pekerjaan. Tim dapat membatasi diskusi setiap user story dan memindahkan pekerjaan yang belum siap ke sesi refinement berikutnya.
Apa yang dilakukan jika sebuah pekerjaan mendapat nilai sangat besar?
Tinjau apakah pekerjaan tersebut dapat dipecah menjadi bagian yang lebih kecil. Nilai besar juga dapat menunjukkan ketidakpastian atau dependensi yang belum diselesaikan.
Kesimpulan
Planning Poker membantu tim membangun pemahaman bersama sebelum pekerjaan dimulai. Nilai kartu bukan tujuan akhir. Nilai tersebut merupakan alat untuk membuka percakapan mengenai kompleksitas, ruang lingkup, risiko, pengujian, dan dependensi.
Gunakan story point sebagai ukuran relatif dalam tim yang sama. Hindari mengubahnya menjadi target produktivitas, membandingkan velocity antartim, atau mengonversinya secara tetap menjadi jumlah jam.
Ketika dikombinasikan dengan refinement yang baik, kriteria penerimaan yang jelas, dan evaluasi metrik sprint secara sehat, Planning Poker dapat meningkatkan kualitas perencanaan tanpa menciptakan kepastian palsu.
Referensi Lanjutan
Untuk mempelajari metrik Agile lebih lanjut, baca panduan Agile Metrics dari Atlassian .