Agile Story Point

 Menurut definisi dari Atlasian "Story Point adalah ukuran estimasi untuk mengerjakan sebuah product backlog atau sebuah kerjaan. Estimasi terhadap rumitnya, resikonya, lamanya, banyaknya sebuah pekerjaan". Inti dari story point adalah estimasi ukuran pekerjaan.

contoh ukuran teknik untuk menentukan estimasi ukuran story point :

1. Planning Poker 

teknik estimasi ukuran story point dengan planning poker adalah point nya mengikuti angka Fibonacci yaitu 1,3,5,8,13,21, dst.

2. Ukuran T-Shirt

teknik ini meng-estimasi ukuran pekerjaan dimana nilai point nya mengikuti ukuran baju yaitu XS, S, M, L, XL, XXL

3. Bucket System

teknik pengukuran pekerjaan dengan bucet system adalah mengukur pekerjaan dengan nilai point 0,1,2,3,4,5,8,13,20,30,50,100,200.

4. Dot Voting

titik sebagai tanda estimasi dari setiap tim

5. Affinity Estimation

estimasi dengan mengumpulkan story yang sejenis.

sebenarnya masih banyak teknik untuk melakukan estimasi ukuran pekerjaan, biasanya yang paling sering di pakai adalah Planning Poker yaitu point nya mengikuti nilai Fibonacci.

estimasi ini mempunyai banyak manfaat yaitu mempermudah tim untuk mengukur kemampuan tim dan tugas yang akan di selesaikan dan mempermudah tim dan product owner untuk menentukan seberapa banyak value yang bisa dideliver di setiap sprint.

pendekatan dengan story point ini adalah alternatif pendekatan estimasi man-hour yang biasa digunakan pada project konvensional.

BAGAIMANA KALAU ESTIMASI KITA TERNYATA MELESET?

misal pada awal kita mengestimasikan nilai storynya adalah 3 story point, ternyata ketika eksekusi pekerjaan nya cukup sulit yang setara dengan 5 story point. 

Apa yang mestinya kita lakukan? 

apakah kita perlu mengubah story point nya menjadi 5 atau biarkan saja story point nya tetap 3?

Satu hal yang perlu diingat adalah Story Point dan Velocity bukanlah sesuatu yang dianggap bagian dari Scrum. Sehingga untuk kasus diatas, dikembalikan lagi ke tim, bagaimana sebaiknya mengatur dan menyikapi kasus diatas.

Biasanya ada 2 pendekatan untuk masalah ini :

Pendekatan pertama mengacu kepada estimasi pada dasarnya hanyalah perkiraan, sehingga kalaupun meleset, maka dianggap tidak apa-apa. Tidak perlu untuk mengubah story point yang sudah kita estimasi dari awal. Evaluasi mengenai estimasi yang meleset ini bisa dibahas di sprint Retrospective. Agar nanti bisa diperbaiki di sprint berikutnya. Bisa jadi karena kita tidak memperhitungkan faktor risk dalam penentuan story point, atau story nya tidak detil sehingga kita tidak tepat dalam estimasi story point.

Pendekatan kedua mengacu kepada esensi bahwa sprint haruslah merepresentasikan kapasitas tim dalam melakukan sesuatu. Yang digambarkan dari jumlah story point. Dalam hal ini mengubah story point merupakan salah satu cara untuk mencapai tujuan tersebut. Dan hal ini sah-sah saja karena cukup beralasan.

Kesimpulannya :

Dua pendekatan diatas boleh-boleh saja, tetapi biasanya yang dilakukan adalah pendekatan pertama, dimana story point adalah dianggap sebagai estimasi saja, yang bisa salah dan bisa benar. Tidak perlu mengubah story point yang sekarang. Jadikan kesalahan itu sebagai bahan perbaikan di sprint berikutnya.