Story Point – Pernahkah kamu mengerjakan sebuah projek namun bingung menentukan estimasi waktu kapan selesai projek tersebut? Mungkin kamu sudah pernah mencoba mengestimasi suatu fitur, kamu berusaha membuat estimasi yang seakurat mungkin. Sayangnya, ini bukanlah hal yang mudah.
Selalu ada saja kemungkinan bahwa estimasi yang kamu buat belum akurat. Meskipun demikian, kamu berharap nilai kenyataannya tidak berbeda jauh dari nilai estimasi kita.
Di sinilah peran story point sangat dibutuhkan. Saat kamu mulai mendefinisikan kebutuhan client dalam user story, kamu direkomendasikan menuliskan estimasinya menggunakan story point. Lalu apa sih itu story point? berikut penjelasan lengkapnya.
Pengertian Story Point
Story Point adalah ukuran atau estimasi untuk mengerjakan sebuat product backlog atau sebuah kerjaan. Estimasi terhadap rumitnya, resikonya, lamanya, dan banyaknya sebuah pekerjaan.
Setiap tim dalam sebuah projek memberikan nilai poin berdasarkan kompleksitas, jumlah,ketidakpastian pekerjaan, dan resiko kegagalan.
Story Point erat kaitannya dengan Agile, poin yang dibuat biasanya diimplementasikan dalam numerik atau huruf yang memiliki tingkatan untuk membantu tim dalam mengidentifikasi tingkat kesulitan dari sebuah story.
Bagaimana Cara Membuat Story Point?
Pendekatan estimasi dengan story point adalah alternatif pendekatan estimasi selain pendekatan man-hour yang biasa digunakan di proyek konvensional. Berikut ini adalah contoh ukuran estimasi story point yang sering digunakan.
Yang paling terkenal dan biasa digunakan di sprint planning adalah teknik planning poker. Yang pointnya adalah mengikuti pola Fibonacci, yaitu 1, 3, 4, 8, 13, 21, dan seterusnya.
| Teknik Estimasi | Ukurannya |
|---|---|
| Planning Poker | 1,3,5,8,13,21,dst |
| Ukuran T-Shirt | XS,S,M,L,XL,XXL |
| Bucket System | 0,1,2,3,4,5,8,13,20,30,50,100,200 |
| Dot Voting | Titik sebagai tanda estimasi dari tiap anggota tim |
| Affinity Estimation | Estimasi dengan mengumpulkan story yang sejenis |
Secara umum, estimasi ini mempunyai banyak manfaat, antara lain:
- Memudahkan tim untuk mengukur kemampuan tim dan tugas yang akan dihadapi/diselesaikan.
- Memudahkan tim dan product owner untuk menentukan seberapa banyak value yang bisa di deliver di setiap sprint.
Mengapa Harus Menggunakan Story Point di Agile?
Story point di dalam Agile bermanfaat untuk tim pengembang dan product owner, antara lain:
Untuk tim pengembang (developers):
- Tim mendapatkan pemahaman yang lebih baik tentang apa yang diminta dari mereka, sehingga lebih mudah mengembangkan strategi penerapan yang baik.
- Tim tidak akan membuat rencana berlebihan, sehingga mereka memiliki kesempatan yang lebih baik untuk menyelesaikan setiap task dan increment.
- Tim tahu berapa banyak yang harus direncanakan dalam sprint, sehingga membuat mereka bekerja dengan efektif dan efisien.
- Tim dapat membuat perkiraan yang masuk akal tanpa harus berkomitmen pada jangka waktu tertentu.
Untuk product owners:
- Product owners dapat menilai laba atas investasi atau return of investment (ROI) atau nilai sebuah produk dengan lebih baik.
- Dapat lebih memahami risiko teknis yang terkait dengan produk yang berukuran lebih besar.
- Memperkirakan delivery product jangka panjang ke client dengan lebih baik.
Setiap anggota tim harus berhati-hati dalam menentukan nilai dari setiap story yang akan dikerjakan, berikut ini adalah beberapa tips yang dapat kamu lakukan, antara lain:
- Jangan memberikan story point untuk tugas-tugas yang sangat mudah atau kecil.
- Pembuatan story point adalah upaya tim, bukan hanya perorangan. Pastikan tim tetap terlibat, dan semua orang berkontribusi.
- Jangan membuat semua task memiliki nilai berdasarkan rata-rata seluruh story point.
- Jangan biarkan satu variabel mempengaruhi keseluruhan proses story point.
Siapa yang Membuat Story Point?
Tim mengunakan story point dalam proses pengembangan aplikasi perangkat lunak dengan metode Agile. Estimasi story point biasanya terjadi selama sesi perawatan product backlog, yang dilakukan oleh tim pengembangan dan pengujian saat meninjau product backlog.
Sangatlah penting diketahui bahwa orang yang melakukan estimasi product backlog adalah orang yang bertanggung jawab untuk melakukan pekerjaan tersebut. Scrum Master tim, product owner, team lead, maupun manajemen tidak memiliki kewajiban untuk membuat story point kecuali mereka ikut mengerjakan sebuah task dalam projek.
Karena kemungkinan besar mereka tidak terjun langsung dalam proses pembuatan aplikasi (programming), mereka biasanya menunggu hasil dan membiarkan profesional yang benar-benar melakukan pekerjaan menentukan kesulitan relatif dari setiap story point.
