Bagaimana Memperkirakan Poin Cerita untuk Proyek Anda?

Saat mengerjakan proyek Agile, tim merencanakan pekerjaan untuk sprint mendatang dengan membuat cerita. Sebuah cerita mendefinisikan satu aktivitas yang dikemas secara fungsional dengan deskripsi dan kriteria penerimaan.

Sprint biasanya berlangsung dari dua hingga empat minggu. Dalam kurun waktu tersebut, tim perlu memahami seberapa banyak konten yang dapat mereka ambil dalam satu sprint sehingga mereka tetap dapat melakukannya dalam waktu sprint yang diberikan.

Pada proyek yang tidak gesit, Anda akan memperkirakan pekerjaan biasanya dalam hari kerja. Artinya, berapa banyak karyawan penuh waktu yang Anda perlukan untuk menyelesaikan aktivitas ini? Dalam hal ini, Anda selalu memikirkan hari dan jumlah orang saat membuat estimasi.

Pada proyek tangkas, segalanya berbeda. Anda tidak lagi menghitung hari atau orang untuk menghitung perkiraan akhir. Bahkan, kami akan melarang bahkan menghitung upaya dalam sesuatu seperti hari manusia. Alih-alih, Anda membiarkan tim mengonversi ke satu nilai yang diterima secara umum untuk cerita yang akan mewakili perkiraan keseluruhan.

Sekarang untuk apa sebenarnya nilainya, ini tidak terlalu penting. Benar, perwakilan estimasi cerita yang paling umum adalah Poin Cerita. Itu pada dasarnya adalah angka Fibonacci mulai dari 0, 1, 2, 3, 5, 8, 13, 21, dll. Nilai selanjutnya adalah jumlah dari dua angka sebelumnya. Ini akan membantu membedakan kompleksitas cerita secara keseluruhan, karena setiap angka yang lebih tinggi berikutnya secara signifikan lebih tinggi dari yang sebelumnya.

Tetapi Anda tidak perlu terpaku pada poin cerita. Bisa berupa perkiraan ukuran kaos (XXS, XS, S, M, L, XL, XXL). Jika Anda ingin benar-benar kreatif, Anda dapat memperkenalkan hewan kebun binatang dan menggunakannya untuk memperkirakan ukuran.

Either way, sekarang lebih banyak tentang perasaan seluruh tim tentang nomor (atau hewan) mana yang paling mewakili kompleksitas keseluruhan dari cerita khusus ini. Ini jelas bukan tentang representasi waktu. Pada akhirnya, tim harus menyelesaikan setiap cerita yang dibawa ke dalam sprint dalam sprint tersebut. Jadi waktu sudah diberikan di awal dan merupakan bilangan konstan.

Komponen Estimasi Poin Cerita

Estimasi poin cerita sama sekali tidak hanya tentang seberapa kompleks / sulitnya sebuah cerita tertentu. Saat memperkirakan sebuah cerita, tim harus mempertimbangkan beberapa aspek dan merefleksikannya dalam nilai estimasi akhir.

Estimasi akhir kemudian merupakan nilai yang mewakili kombinasi dari semua aspek yang dibentuk menjadi satu angka. Inilah yang termasuk perkiraan tersebut.

#1. Kesulitan Teknis

Dengan asumsi kami memperkirakan cerita untuk tim pengembangan, kesulitan teknis cerita akan menjadi salah satu area pertama yang akan menjadi fokus tim secara default.

Dan ini, tentu saja, pendekatan yang tepat. Tim yang penuh dengan pakar teknis harus tahu cara terbaik mengevaluasi area cerita seperti itu. Di sini tim dapat mempertimbangkan berbagai pendekatan atau petunjuk, seperti:

• Bagaimana cerita ini dibandingkan dengan cerita lain yang sudah disampaikan dari sudut pandang kerumitan teknis?
• Berapa banyak file kode yang harus dibuat/diperbarui oleh tim untuk menyelesaikan cerita?
• Berapa banyak perubahan kode tambahan yang akan dihasilkan cerita ini ke proses sistem di sekitarnya?
• Seberapa rumit algoritma atau logika proses untuk diimplementasikan?

#2. Ketergantungan dan Risiko Eksternal

Orang akan terkejut, tetapi lebih sering daripada tidak, kesuksesan cerita di dalam sprint tim bergantung pada kontribusi dari tim lain atau orang di luar tim itu sendiri.

Cerita di mana semua yang dapat diselesaikan oleh tim sendiri adalah yang paling mudah diperkirakan. Segalanya menjadi rumit jika tim membutuhkan bantuan eksternal untuk cerita mereka. Bagi orang-orang di luar tim, tentu saja kegiatan ini tidak akan menjadi prioritas. Tim hanya perlu mengandalkan faktor itu dan mempertimbangkannya dalam estimasi.

Seberapa besar faktor ini akan meningkatkan estimasi total akan sangat bergantung pada pengalaman tim sebelumnya dan “tingkat eksternalitas”. Biasanya, dalam beberapa sprint, tim akan membangun perasaan kesatuan yang alami tentang seberapa besar ketergantungan pada orang luar ini dapat mempersulit penyelesaian cerita yang berhasil.

#3. Faktor Dapat Digunakan Kembali

Area selanjutnya yang perlu dipertimbangkan adalah seberapa banyak konten yang ada yang dapat digunakan kembali oleh tim untuk menyelesaikan cerita. Jelas, jika beberapa bagian sudah ada dengan satu atau lain cara, tidak perlu membuatnya dari awal. Sebaliknya, tim dapat menggunakan kembali solusi yang sudah pernah dibuat untuk membuat solusi baru dengan lebih cepat.

Sedemikian rupa, pengetahuan ini dapat menurunkan perkiraan total, meskipun biasanya (tanpa penggunaan ulang ini), ceritanya akan menjadi lebih kompleks berdasarkan konten yang ditentukan.

#4. Pengertian Tim Sendiri

Salah satu faktor luar biasa yang tidak dapat dipertimbangkan oleh perkiraan berbasis hari kerja adalah pengetahuan diri tentang senioritas dan kemampuan tim.

Saat tim bekerja sama dan melakukan beberapa sprint, orang-orang di dalamnya akan saling mengenal. Mereka akan mulai memahami siapa yang tahu apa dan seberapa baik dia dalam hal itu. Dan begitu semua orang mengetahui anggota tim lainnya, mereka bersama sebagai satu tim dapat mempertimbangkan hal ini selama estimasi.

Jika ceritanya berat pada beberapa keterampilan teknis konkret dan keterampilan itu sangat kuat hadir di dalam tim, realisasi cerita yang jelas tidak akan terlalu merepotkan. Atau sebaliknya, jika keterampilan yang dibutuhkan kurang dalam seluruh tim, maka tim akan membutuhkan lebih banyak waktu secara signifikan untuk masuk ke topik, dan mereka akan mencerminkannya dalam perkiraan.

Memperkirakan Cerita

Setiap estimasi cerita harus menjadi upaya tim. Tidak ada satu suara pun yang dapat menentukan kompleksitas cerita. Tujuan utamanya adalah membiarkan tim mendiskusikan perkiraan sampai semua anggota menyetujui satu nilai tunggal yang akan mewakili perkiraan akhir.

Tim dapat melakukan estimasi secara langsung selama diskusi penyempurnaan sprint (pertemuan di mana cerita didiskusikan dan diklarifikasi di antara tim), atau sebagai alternatif, mereka dapat menyediakan waktu khusus untuk melakukan hal itu.

Contoh Proses Estimasi

Pilih alat estimasi untuk digunakan tim, seperti Perencanaan Poker, papan Miro, atau sejenisnya.

Letakkan sebuah cerita di papan tulis. Biarkan tim mendiskusikan pemikiran atau pertanyaan terakhir tentang cerita tersebut. Pastikan seluruh tim memiliki pemahaman penuh tentang cerita tersebut dan mereka siap untuk memperkirakan.

Mulai estimasi. Setiap anggota tim diminta untuk memilih angka dari skala Fibonacci.

Setelah semua sudah diperkirakan, lihat bersama hasilnya. Mulai diskusi. Biasanya, tim akan memisahkan antara dua hingga tiga angka. Biarkan orang-orang dari ujung bawah memberikan alasan mengapa perkiraan harus serendah ini. Kemudian biarkan orang-orang dari ujung sana menguraikan mengapa perkiraan akhir harus setinggi ini. Tujuannya adalah untuk menyajikan semua argumen, pertimbangan, dan fakta sehingga seluruh tim memiliki pemahaman yang sama dalam memahami isi cerita ini.

Setelah diskusi selesai, biarkan tim memperkirakan lagi. Sebagian besar waktu, tim sekarang akan mengonversi ke satu atau dua angka berbeda. Ulangi diskusi lagi. Bergantung pada kasus konkretnya, tim akan menyepakati angka akhir dari dua alternatif, atau Anda akan memutuskan putaran estimasi lainnya.

Estimasi selesai hanya jika semua anggota tim benar-benar baik-baik saja dengan estimasi akhir. Itu harus menjadi kesepakatan seluruh tim, bukan hanya beberapa individu. Secara potensial, setiap cerita nantinya dapat diberikan kepada siapa saja dari tim. Itulah mengapa penting bagi semua orang untuk sepakat tentang betapa rumitnya cerita itu.

Komitmen Rencana Sprint

Tim sekarang memiliki backlog dengan cerita yang sudah melewati sesi estimasi. Idealnya, cerita-cerita tersebut telah ditetapkan (selain dari nilai perkiraan akhir) juga menjadi prioritas sehingga tim mengetahui cerita mana yang akan datang berikutnya ke dalam sprint berikutnya.

Inilah sesi perencanaan, di mana tim akan memilih beberapa cerita untuk sprint berikutnya. Keputusan tentang cerita mana yang akan dipilih harus didasarkan pada hal-hal berikut:

✅ Cerita dengan prioritas tertinggi yang dipertimbangkan tim terlebih dahulu.

✅ Pengalaman tim tentang berapa banyak poin cerita yang dapat mereka selesaikan dalam sprint. Pengetahuan ini hanya datang dengan waktu dan pengalaman tim. Anda memerlukan beberapa sprint untuk menyempurnakan dan mendapatkan pemahaman yang tepat tentang kemampuan ini.

✅ Anda seharusnya tidak hanya mempertimbangkan jumlah dan prioritas poin cerita total. Pertimbangan lain adalah bagaimana keterampilan di dalam tim akan tersebar di cerita yang dipilih. Misalnya, jika tim hanya memiliki dua pengembang front-end, mereka tidak boleh memilih cerita yang hanya terdiri dari pengembangan front-end saja. Itu akan menyebabkan penggunaan kedua orang tersebut secara berlebihan sementara anggota tim lainnya tidak terlalu banyak. Jadi pengetahuan tim berjalan seiring dengan efektivitas pembuatan konten sprint.

Faktor Kecepatan

Yang terpenting adalah kecepatan tim (untuk sprint yang akan datang). Jumlah ini sama sekali tidak terkait dengan jumlah total poin cerita. Namun, ini menunjukkan seberapa banyak tim akan siap bekerja untuk sprint yang akan datang.

Agar dapat merencanakan konten sprint dengan tepat, kami menggabungkan kedua aspek tersebut:

Kecepatan tim – Diukur dalam hari. Satu anggota tim tersedia untuk satu hari penuh sama dengan satu dalam kecepatan tim. Misalnya, tim beranggotakan 10 orang yang sepenuhnya tersedia untuk sprint yang berlangsung selama 2 minggu sama dengan kapasitas tim 100 orang.

Jumlah poin cerita yang biasa diselesaikan dalam sprint – Diukur dalam poin cerita. Angka ini berasal dari pengalaman sebelumnya dan terkait erat dengan kecepatan tim.

Butuh waktu dan latihan untuk menemukan sweet spot.

Manfaat dan Kesalahan Umum

Sungguh mengejutkan betapa banyak tim yang bersedia mempersulit diri mereka sendiri proses sepanjang jalan transformasi menjadi tim yang gesit. Rasanya Anda perlu “mendapatkannya” sebelum Anda dapat mulai bekerja dalam mode itu.

Sayangnya, langkah pertama ini juga yang paling sulit. Dalam beberapa kasus, dibutuhkan bahkan bertahun-tahun, terutama di lingkungan perusahaan yang sangat konservatif, di mana waktu saja macet dalam waktu.

Bagaimanapun, inilah yang akan terjadi setelah tim “mengerti”:

• Anda tidak perlu lagi menghitung orang atau hari untuk mengetahui kapan sesuatu dapat diselesaikan.
• Tim akan belajar membuat cerita sekompleks mungkin agar sesuai dengan sprint. Jika sebuah cerita lebih kompleks, maka secara otomatis akan dibagi menjadi lebih banyak cerita.
• Tim memiliki perkiraan yang baik untuk setiap bagian pekerjaan, dan begitu mereka merencanakannya untuk sprint, Anda tahu persis waktunya.
• Ini akan meningkatkan keandalan dan prediktabilitas tim.
• Semua orang di dalam tim akan “pada frekuensi yang sama”. Mereka akan melihat sebuah cerita dan akan memahami hal-hal serupa. Mungkin setelah beberapa waktu, mereka bahkan tidak peduli untuk memperkirakan. Mereka melihat angka di kepala mereka, dan karena mereka semua melihat angka yang sama, mereka dapat membuat cerita dalam sprint bahkan tanpa perkiraan eksplisit ini.

Dan inilah yang biasanya terjadi jika tim masih belum bisa memahami proses atau cara kerjanya:

• Mereka entah bagaimana masih berpegang pada perkiraan mode man-days lama. Mereka mengubah segalanya menjadi hari atau orang yang terlibat. Poin cerita atau angka Fibonacci berarti jumlah hari, baik secara langsung maupun tidak langsung, melalui berbagai transformasi.
• Kepemimpinan membandingkan tim berdasarkan jumlah poin cerita yang disampaikan setiap sprint. Ini sama salahnya dengan yang bisa terjadi. Fakta substansial kemudian tidak dipahami: Setiap tim memperkirakan poin cerita secara berbeda. Sama sekali tidak ada alasan untuk berusaha menyinkronkan dua tim untuk memperkirakan cerita mereka dengan “cara yang sama”.
  • Sementara poin cerita satu tim berarti menggambar lingkaran, untuk tim lain, itu mungkin berarti menggambar rumah dengan atap datar, empat jendela, dan dua pintu. Dan itu baik-baik saja.
• Terkadang tim cenderung memperkirakan hampir semuanya antara dua hingga empat angka berbeda. Mungkin karena mereka takut sebuah cerita memiliki angka 123, seseorang akan mengira itu ada hubungannya dengan jumlah hari. Namun faktanya skala Fibonacci memiliki jumlah angka yang tidak terhingga. Kita tidak perlu membatasi diri hanya pada perkiraan 3, 5, atau 8. Kita pasti bisa (dan mungkin kita sudah membuat cerita dengan tujuan untuk menjadi sekompleks itu, dalam hal ini baik-baik saja), tetapi kita pasti tidak perlu.
• Estimasi didorong oleh orang-orang senior yang akan menentukan harapan seluruh kelompok. Kita tidak boleh membiarkan mempengaruhi estimasi oleh satu anggota tim. Setiap orang memiliki hak yang sama untuk menyatakan pendapatnya dan didengarkan.

Kata Akhir

Beralih ke perkiraan tangkas dari pendekatan yang lebih tradisional tidak selalu mudah dan perlu mengakomodasi — baik untuk tim maupun kepemimpinan di atas. Agar berhasil, kedua belah pihak harus memahami prosesnya. Jika salah satu dari mereka tidak mengerti, masa transisi adalah jalan yang sulit penuh dengan harapan yang bertentangan.

Tapi begitu semua berubah, beberapa hal ajaib akan mulai terjadi. Tim akan dapat memperkirakan dan merencanakan pekerjaan mereka dengan lebih baik, dan kepemimpinan akan memiliki rilis dan peta jalan yang lebih dapat diprediksi untuk diandalkan.

Selanjutnya, periksa proses tidak sehat yang dapat merusak sprint Anda.