Estimasi Menggunakan Story Point pada User Story

Apakah kamu pernah ditanya oleh klien atau mungkin manajer kamu, “berapa lama ya kira-kira untuk menyelesaikan fitur ini?” Di kondisi seperti ini, kamu mau ga mau harus melakukan yang namanya estimasi, melihat ke depan lalu memperkirakan berapa lama waktu yang dibutuhkan untuk menyelesaikan fitur tersebut. Saat mengestimasi suatu fitur, kita berusaha untuk membuat estimasi yang seakurat mungkin. Sayangnya, ini bukanlah hal yang mudah. Selalu ada kemungkinan bahwa estimasi yang kita buat tidak akurat. Meskipun tidak akurat, kita berharap nilai kenyataannya tidak berbeda jauh dari nilai estimasi kita.

Saat kita memilih untuk menuliskan requirements dalam user story, kita direkomendasikan menuliskan estimasinya menggunakan story point. Yup, story point dibuat untuk mendukung estimasi menggunakan user story dalam pendekatan Agile. Ketika kita membuat suatu user story, kita cenderung menuliskan estimasi dalam waktu, bisa berupa hari atau jam. Misalnya kita mengatakan untuk mengimplementasikan suatu user story dibutuhkan waktu 2 hari. Berbeda dengan estimasi dalam waktu, story point pada user story tidak menggunakan satuan waktu dan hanya menuliskan nilai tanpa satuan. Story point mungkin saja berkorelasi dengan waktu, tapi itu tidak selalu terjadi. Menarik kan konsep dari story point? Mari kita bahas lebih dalam. 😀

Story point menggambarkan usaha (effort) yang dibutuhkan untuk menyelesaikan implementasi suatu user story. Nilai usaha ini akan dipengaruhi oleh kompleksitas dan resiko saat implementasi user story tersebut. Makin sulit menyelesaikan user story tersebut dan makin tinggi resiko yang dihadapi saat implementasinya, nilai story point-nya akan makin lebih besar dari yang seharusnya. Sebagai contoh, suatu user story dituliskan oleh product owner sebagai berikut.

ID: 01
Sebagai penjual, saya ingin menambahkan barang baru sehingga saya bisa jualan barang baru tersebut

Untuk mengetahui maksud dari user story di atas lebih jauh, kita perlu menanyakan beberapa pertanyaan ke product owner seperti info apa saja yang diperlukan untuk menambahkan barang baru ke sistem, mana info yang wajib diisi oleh penjual dan mana yang opsional. Product owner selanjutnya menjelaskan info apa saja yang diperlukan untuk menambahkan barang baru. Namun sayangnya, itu semua masih asumsi product owner dan dia mengatakan bahwa info tersebut mungkin saja berubah. Product owner ingin bertemu dengan beberapa representasi calon penjual terlebih dahulu untuk mendapatkan info penambahan barang baru yang sesuai kebutuhan penjual. Dalam ketidakpastian ini, memilih user story tersebut untuk dikerjakan saat ini tentu saja memiliki resiko lebih. Dalam hal ini, kita bisa menaikkan nilai story point dari yang seharusnya kita pikir lalu merevisinya di kemudian hari saat sudah ada info yang lebih akurat dari product owner.

Hal yang menarik dari story point adalah story point tidak menggunakan satuan waktu dalam estimasi seperti hari atau jam. Well, that is surprising for me for the first time! Story point malahan menggunakan nilai tanpa satuan. Nilai tersebut menggambarkan banyaknya usaha yang relatif terhadap user story lainnya yang kita miliki. Seandainya saya memilih suatu user story yang saya anggap mudah dan sederhana, saya bisa menjadikan user story tersebut sebagai user story dasar untuk mengestimasi user story lain. Saya bisa menilai user story lain lebih besar usahanya dua kali, tiga kali, atau lima kali lipat berdasarkan user story dasar yang saya pilih.

Ada dua buah pendekatan dalam menuliskan story point yang populer digunakan, yaitu menggunakan angka dan menggunakan ukuran baju.

Story Point dalam Angka
Story point bisa direpresentasikan dengan angka untuk menggambarkan usaha yang dibutuhkan untuk mengimplementasikan suatu user story. Pada dasarnya, kita bisa menuliskan sembarang angka dalam bilangan bulat positif sebagai estimasi pada suatu user story, misalnya 2, atau 8, atau mungkin 100, asalkan tetap memenuhi sifat relatif-nya story point. Sebagai contoh, kita memiliki suatu user story yang dianggap mudah. Kemudian kita memberikan nilai estimasi 100 untuk user story tersebut dan menjadikannya sebagai user story dasar. Seandainya kita memiliki user story lain yang kita pikir banyaknya usaha dua kali lipat dari user story dasar, user story lain tersebut kita beri nilai 200.

Untuk membuat estimasi lebih mudah dan sederhana, ada dua buah cara yang digunakan dalam menuliskan angka sebagai estimasi. Yang pertama adalah menggunakan angka yang bernilai relatif kecil daripada angka yang relatif besar. Dan yang kedua adalah menggunakan bilangan Fibonacci daripada bilangan bulat positif.

Untuk suatu user story, developer lebih mudah membayangkan banyaknya usaha pada user story bernilai 3 terhadap user story dasar bernilai 2. Implementasi user story bernilai 3 membutuhkan usaha 50% lebih banyak dari user story dasar, atau 1.5 kali lipat dari user story dasar. Implementasi user story bernilai 8 membutuhkan usaha 4 kali lipat dari user story dasar. Jika user story dasar awalnya sudah bernilai 50, user story yang usahanya 1.5 kali lipat akan bernilai 75 dan user story yang usahanya 4 kali lipat akan bernilai 200. Meskipun memungkinkan menggunakan angka yang besar, menggunakan angka yang kecil tentu saja lebih praktis.

Penggunaan bilangan Fibonacci akan membuat estimasi jadi lebih sederhana. Bilangan Fibonacci adalah bilangan yang diperoleh dari urutan angka yang dimulai dari angka 0 dan 1, kemudian angka-angka berikutnya diperoleh dengan menjumlahkan dua angka sebelumnya.

Bilangan Fibonacci:
0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, …

Jika melihat arti di balik angka pada suatu user story, makin tinggi nilai story point-nya, makin tidak penting keakuratannya. Misalnya ketika dua developer dalam satu tim yang sama mencoba mengestimasi suatu user story. Seorang developer memberi angka 3, yang satunya memberi angka 2. Melihat perbedaan angka ini, kedua developer tersebut berdiskusi mengenai apa yang mereka asumsikan dan pahami mengenai user story tersebut hingga mereka mendapatkan kesepakatan nilai estimasi yang sama untuk user story tersebut. Perbedaan nilai ini cukup signifikan karena user story dengan angka 3 berarti membutuhkan usaha 50% lebih banyak dari user story dengan angka 2. Kemudian kedua developer tersebut berlanjut ke user story yang lain. Seorang developer memberi angka 20, yang satunya memberi angka 23. Di titik ini, mereka bisa langsung sepakat di angka 21 dengan mengambil angka terdekat dari nilai estimasi mereka pada bilangan Fibonacci. User story dengan angka 23 berarti membutuhkan usaha 9.5% lebih banyak dari user story yang dipilih dengan angka 21. User story dengan angka 20 berarti membutuhkan usaha 4.7% lebih sedikit dari user story yang dipilih dengan angka 21. Perbedaan nilai estimasi ini dianggap tidak signifikan. Jika ternyata implementasi user story tersebut membutuhkan usaha lebih banyak dari yang diperkirakan, kedua developer tersebut berharap usaha ekstra yang dibutuhkan relatif tidak banyak. Jika ternyata lebih sedikit, mereka bisa menggunakan “usaha yang tersisa” untuk mengimplementasikan user story yang lain atau sekedar menutup “usaha ekstra” di story yang lain.

Story Point dalam Ukuran Baju
Ini sebenarnya adalah representasi angka yang disederhanakan menjadi beberapa kategori. Estimasi dituliskan dalam ukuran baju dalam menggambarkan usaha implementasi dari suatu user story. Sebagai contoh, kita bisa mendefinisikan 6 jenis ukuran, yaitu:

XS (Extra Small)
S (Small)
M (Medium)
L (Large)
XL (Extra Large)
XXL (Extra Extra-Large)

User story yang dianggap kecil usaha implementasinya dan umumnya sederhana bisa diberi nilai XS atau S. User story yang dianggap besar dan kompleks bisa diberi nilai L. User story yang kira-kira tidak besar tapi juga tidak kecil, dan tidak kompleks tapi juga tidak sederhana, bisa kita beri nilai M. Jika kita pikir ketidakpastian dalam implementasi suatu user story makin tinggi yang berarti usaha implementasinya makin besar, kita bisa mempertimbangkannya untuk memberikan nilai XL atau XXL. Sederhana kan? 😀

—

Dalam kaitannya dengan waktu, story point efektif digunakan dalam pengembangan yang iteratif. Untuk suatu iterasi (rentang waktu tertentu), kita bisa memilih seberapa banyak user story yang ingin kita ambil untuk dikerjakan dalam rentang waktu tersebut. Dengan kata lain, kita memilih jumlah story point yang mampu kita ambil dalam satu iterasi. Di penghujung iterasi, kita bisa menghitung jumlah story point yang dikumpulkan dari user story yang berhasil diselesaikan dan itu akan menjadi masukan untuk iterasi berikutnya.

Story point adalah cara baru dalam estimasi. Menggunakan story point dalam mengestimasi user story adalah hal yang direkomendasikan meskipun agak sulit saat pertama kali mencobanya. Story point memberikan pengalaman baru bagi kita dalam mengestimasi kerjaan pengembangan software. And it is worth to try.

Jika kamu punya pertanyaan mengenai story point ini, silakan langsung tanya saja di kolom komentar di bawah ini. 😀

Happy learning!

 

Referensi:

1. Cohn, Mike. User Stories Applied: For Agile Software Development. Boston: Pearson Education, 2004. Print.
2. Ambler, Scott W., and Matthew Holitza. Agile for Dummies, IBM Limited Edition. Hoboken: John Wiley & Sons, 2012.