Untuk melihat apa itu Story Point.

Kenapa harus pakai story point sih ?

Menambahkan story point dalam melakukan estimasi sebuah kerjaan sebenarnya menambah pertanyaan tambahan :

  • Kenapa estimasi tidak langsung dalam bentuk hari saja sih ?
  • Saya butuh mengkonversi story point ke jumlah hari juga kan jadinya ?
  • Story point ini bukannya sebuah cara estimasi yang baru saja ?, yang menambahkan kebingungan terhadap tim lagi kan ?

Pertanyaan ini sebenarnya ada penjelasan di salah satu artikel ManHour

Tetapi apabila jabaran di artikel tersebut tidak menjawab, bisa disimak jabaran di sini :

Kenapa harus pakai story point sih ?

Perlu diingat untuk kasus story point :

  • Story point itu cuma alat estimasi.
  • Story point selain untuk mengukur estimasi kerjaan, juga untuk mengukur kapasitas tim. Jadi semangatnya adalah semangat tim. Ini berefek banyak kepada tanggung jawab, kekompakan, dan juga kelincahan tim. Estimasi dengan manhour lebih berimplikasi kepada individu, menekankan tanggung jawab indidivu, dan tentunya juga akan berakibat kepada kekompakan dan kelincahan tim.
  • Story point mengubah mindset baik dari sisi tim dan management untuk cocok dengan prinsip Agile. Lihat prinsip Agile disini Agile Manifesto. Salah satunya misalnya :

Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

Bagaimana ceritanya prinsip waterfall akan cocok dengan prinsip ini ?

Tentunya Project Manager Anda akan marah-marah, atau minta tambahan waktu dan tambahan uang tentunya untuk mengakomodasi hal ini.

Atau bisa jadi Project Manager akan melakukan eskalasi tingkat tinggi hanya karena hal seperti ini.

Manhour di konsep waterfall artinya selain waktu perjam, juga artinya biaya per jam untuk melakukan proses development.

Story point sebagai salah satu alat bantu dalam estimasi tim Agile, akan lebih cocok dengan kasus ini.

Penambahan requirement di akhir-akhir development, akan bisa disiasati dengan cara :

  • secara akumulasi point atau velocity akan diusahakan tetap sama, dengan cara mengganti dengan story lain yang sama, atau istilahnya mungin tukar guling.
  • Story point dibuat dengan elastisitas yang cukup untuk sebuah pekerjaan, sehingga waktu tidak habis untuk reestimasi lagi.

Story point dibuat dengan cara yang tidak saklek secara waktu. Hal ini memudahkan dalam melakukan proses elastisitas dalam delivery value.

Misalnya delivery sesuatu kerjaan yang dihargai dengan 3 point, akan tetapi karena ada production issue, maka dibuatlah kerjaan itu dilakukan dengan bobot 1 story point saja, untuk tujuan delivery value sebagian.

Tergantung dari tim dan Product Owner untuk memastikan bobot 2 story point lagi apakah masih visible atau bagaimana baiknya nantinya.

Bagi client, ini juga lebih fair, terutama menyangkut mengenai kejujuran dan hasil yang didapatkan. Client juga mengetahui mengenai kesulitan yang terjadi dan mendapatkan pengetahuan yang cukup untuk menerima permasalahan tersebut.

Misalnya lagi, ketika untuk kasus prinsip agile :

Simplicity–the art of maximizing the amount of work not done–is essential.

Bagaimana prinsip waterfall akan cocok dengan prinsip ini ?

Ketika diwaktu ditengah development, ternyata tim menemukan bahwa fitur yang sedang dibangun sebenarnya tidak efektif.

Tim waterfall tentu saja tidak peduli. Selama saya dibayar, tentunya saya kerjakan.

Tim Agile tentunya bisa bereksperimen dengan hal ini. Sesuatu yang tidak efektif bisa diusulkan untuk tidak dikerjakan, dan berarti pula bobot pekerjaan dengan story point bisa berkurang, dan bisa ditukar guling dengan pekerjaan lain, atau bisa membantu rekan sekerja untuk menyelesaikan delivery goal.