Story Point vs Man Hour

Pertanyaan mendasar mengenai story point yang muncul adalah :

Kalau story point itu intinya adalah estimasi, kenapa tidak dipakai saja estimasi dalam bentuk man-hour.?

Dikutip dari Wikipedia, Man-hour adalah :

Estimasi seberapa banyak pekerjaan dapat dilakukan oleh seseorang dalam waktu satu jam.

Misalnya sebuah pekerjaan membuat sebuah tampilan CRUD (Create, Read, Update, dan Delete) memakai Spring Boot, Angular, dan MySQL, bisa dilakukan dalam waktu 4 man-hour tanpa henti.

Sementara kalau diestimasi menggunakan story point, maka kemungkinan bisa menjadi 5 story point, atau bisa jadi 8 point, tanpa menunjukkan berapa sebenarnya man-hour yang dibutuhkan.

Secara kasat mata, story point tidak bisa menjadi patokan di dalam menentukan berapa lama kah sebuah story/tugas selesai dilaksanakan.

Hmm.., kedengarannya lebih menjanjikan dan memuaskan kalau diestimasi dengan man-hour ya ?

Kenapa bisa dibilang begitu ?

Hal ini karena :

  1. Lebih pasti dalam menentukan estimasi tanggal launching/release berdasarkan jumlah man-hour.
  2. Lebih mudah mengalokasikan anggota tim development dalam menyelesaikan sebuah story.
  3. Tim akan lebih terencana dan terstruktur dalam membagi waktu pengerjaan tugas.

Apakah sesuai dengan kenyataannya ?

Kenyataannya :

  1. Estimasi kita sering meleset.
    Sebuah tugas yang diestimasi cuma 4 jam, bisa saja menjadi 6 jam atau bahkan 8 jam. Biasanya kita mengestimasi waktu berdasarkan asumsi bahwa semuanya akan berjalan tanpa hambatan. Biasanya pula, kita akan menambahkan buffer time untuk menjaga waktu extra yang dibutuhkan itu, sehingga kita tidak melewati batas waktu tersebut.

    Karena kenyataannya memang kadangkala tugas yang kita kerjakan tidak semudah atau tidak sesulit yang kita pikirkan/definikan dari awal.
  1. Tidak semua anggota tim mempunyai kemampuan yang sama.
    Di dalam tim, kemampuan tiap orang berbeda-beda. Itu adalah satu hal yang natural.
    Ada yang cepat menyelesaikan persoalan, ada yang baru bergabung di tim, ada yang cara menyelesaikan sebuah tugas tipikalnya terburu-buru, ada yang mesti menganalisa lebih dalam dulu, ada yang tidak bisa diganggu sama sekali kalau sedang mengerjakan sebuah tugas, dll.

    Penentuan man-hour tidak akan bisa menjangkau semua keberagaman yang ada di dalam tim. Kecuali dari awal sudah ditentukan bahwa orang tertentu akan memegang tugas yang spesifik yang diestimasi menggunakan man-hour. Pada kasus ini man-hour masih relevan. Tetapi kalau ditengah jalan, orang yang bersangkutan berhalangan untuk bekerja, seperti sakit, izin, dll, maka man-hour menjadi momok menakutkan bagi tim.

  1. Secara mental, tim development lebih fleksibel dalam mengatur rencana dan estimasi menggunakan story-point.
    Man-hour biasanya dibuat berdasarkan waktu mengerjakan sesuatu tanpa diganggu dengan hal lain. Berdasarkan itu dibuatlah dateline. Sehingga dengan man-hour yang sudah terdefinisi dari awal, bisa dengan tepat ditentukan bahwa sebuah kerjaan akan selesai pada hari apa.

    Tetapi banyak kasus-kasus tertentu yang waktu yang dibutuhkan untuk mengerjakan sesuatu sesuai dengan estimasi, tetapi tetap tidak memenuhi dateline. Hal ini bisa saja terjadi karena adanya meeting, diskusi, melakukan support untuk production, support dengan tim lain, administrasi kerjaan, dll, sehingga dateline nya tidak tercapai.
    Istilahnya ada prioritas lain yang didahulukan sehingga kerjaan tidak sesuai dengan dateline.

    Tidak mencapai dateline ini menjadi alasan bagi manajemen untuk mempertanyakan kapasitas tim.

    Padahal masalahnya bukan di estimasinya, tetapi dari perubahan prioritas dan hal lain yang mengganggu tim. Dengan story point, hal ini bisa terakomodasi karena tidak ditentukan man-hour nya tetapi lebih fleksibel tergantung dari prioritas tim saat itu.

Kesimpulan

Dengan story point, yang dilihat lebih ke fleksibilitasnya, sementara dengan man-hour lebih kepada komitmen kepada dateline dan jamnya.