Konversi Effort estimation dengan menggunakan User Story Points

Dalam pengembangan perangkat lunak, salah satu tantangan terbesar adalah menentukan berapa lama suatu proyek akan memakan waktu. Ada banyak faktor yang mempengaruhi durasi proyek, seperti kompleksitas, ketergantungan, risiko, kualitas, dan sumber daya. Oleh karena itu, penting untuk memiliki metode yang dapat mengukur usaha yang diperlukan untuk menyelesaikan proyek dengan akurat dan konsisten.

Salah satu metode yang populer digunakan oleh tim agile adalah user story points. User story points adalah satuan ukuran yang menggambarkan tingkat kesulitan atau usaha yang dibutuhkan untuk mengerjakan sebuah user story. User story adalah deskripsi singkat tentang fitur atau fungsi yang diinginkan oleh pengguna. User story points tidak berdasarkan pada waktu, melainkan pada faktor-faktor seperti ukuran, kompleksitas, ketidakpastian, dan risiko.

User story points membantu tim agile untuk melakukan perencanaan sprint, yaitu periode waktu tertentu (biasanya dua minggu) di mana tim berkomitmen untuk menyelesaikan sejumlah user story. Dengan menggunakan user story points, tim dapat memperkirakan berapa banyak user story yang dapat mereka kerjakan dalam satu sprint, dan seberapa cepat mereka dapat menyelesaikan proyek secara keseluruhan.

Namun, user story points memiliki beberapa kelemahan. Pertama, user story points bersifat subjektif dan relatif. Artinya, nilai user story points dapat berbeda-beda tergantung pada pengalaman, pengetahuan, dan preferensi masing-masing anggota tim. Misalnya, user story yang dianggap mudah oleh seorang developer senior mungkin dianggap sulit oleh seorang developer junior. Hal ini dapat menyebabkan inkonsistensi dan ketidakakuratan dalam estimasi usaha.

Kedua, user story points tidak mudah dikonversi menjadi satuan waktu. Meskipun user story points tidak dimaksudkan untuk mengukur waktu, tetapi seringkali stakeholder proyek (seperti manajer, klien, atau sponsor) ingin tahu berapa lama proyek akan selesai. Untuk mengonversi user story points menjadi waktu, tim perlu mengetahui kecepatan (velocity) mereka, yaitu jumlah user story points yang dapat mereka selesaikan dalam satu sprint. Namun, kecepatan tim dapat berubah-ubah dari sprint ke sprint tergantung pada faktor-faktor seperti kualitas kode, perubahan persyaratan, masalah teknis, atau absensi anggota tim. Hal ini dapat menyebabkan kesulitan dan ketidakpastian dalam estimasi waktu.

Oleh karena itu, beberapa tim agile mencoba untuk mengonversi effort estimation dan user story points menjadi satuan waktu yang lebih mudah dipahami oleh stakeholder proyek. Salah satu cara untuk melakukan hal ini adalah dengan menggunakan teknik bernama ideal days atau ideal hours. Ideal days atau ideal hours adalah jumlah waktu yang dibutuhkan oleh seorang developer untuk mengerjakan sebuah user story tanpa gangguan atau hambatan apapun. Ideal days atau ideal hours bukanlah waktu nyata yang dibutuhkan oleh developer untuk mengerjakan user story di dunia nyata, melainkan waktu teoretis yang diasumsikan dalam kondisi ideal.

Untuk mengonversi effort estimation dan user story points menjadi ideal days atau ideal hours, tim perlu melakukan beberapa langkah berikut:

1. Menetapkan skala user story points yang akan digunakan. Biasanya, tim menggunakan skala Fibonacci (1, 2, 3, 5, 8, 13, ...) atau skala eksponensial (1, 2, 4, 8, 16, ...). Skala ini digunakan karena semakin besar nilai user story points, semakin besar pula ketidakpastian dan variabilitasnya.
2. Menentukan nilai ideal days atau ideal hours untuk setiap nilai user story points. Misalnya, tim dapat menetapkan bahwa 1 user story point setara dengan 0.5 ideal days atau 4 ideal hours.
3. Mengestimasi usaha untuk setiap user story dengan menggunakan teknik seperti planning poker atau affinity estimation. Planning poker adalah teknik di mana setiap anggota tim memilih kartu yang menunjukkan nilai user story points yang mereka anggap sesuai untuk user story tersebut. Affinity estimation adalah teknik di mana tim mengelompokkan user story berdasarkan tingkat kesulitannya secara visual.
4. Mengalikan nilai user story points dengan nilai ideal days atau ideal hours untuk mendapatkan estimasi waktu untuk setiap user story. Misalnya, jika user story memiliki nilai 5 user story points, dan 1 user story point setara dengan 0.5 ideal days, maka estimasi waktu untuk user story tersebut adalah 2.5 ideal days.
5. Menjumlahkan estimasi waktu untuk semua user story untuk mendapatkan estimasi waktu untuk proyek secara keseluruhan. Misalnya, jika proyek terdiri dari 10 user story dengan total nilai 40 user story points, dan 1 user story point setara dengan 0.5 ideal days, maka estimasi waktu untuk proyek tersebut adalah 20 ideal days.

Dengan menggunakan cara ini, tim dapat mengonversi effort estimation dan user story points menjadi satuan waktu yang lebih mudah dipahami oleh stakeholder proyek. Namun, tim harus tetap menyadari bahwa estimasi ini bukanlah prediksi yang pasti, melainkan perkiraan yang berdasarkan pada asumsi dan kondisi ideal. Tim harus selalu memantau dan menyesuaikan estimasi mereka sesuai dengan perkembangan proyek dan kecepatan tim.

Mengonversi effort estimation dan user story points menjadi satuan waktu dapat membantu tim agile untuk berkomunikasi dengan stakeholder proyek dengan lebih baik. Namun, tim harus tetap fokus pada nilai dan kualitas dari produk yang mereka kembangkan, bukan hanya pada waktu yang dibutuhkan untuk menyelesaikannya. Jika kalian ada komentar silakan masukan ke kolom komentar, salam #VSID