Poin cerita

Story point adalah satuan estimasi relatif yang digunakan untuk menyatakan seberapa besar suatu pekerjaan dibandingkan dengan pekerjaan lain, bukan berapa lama waktu yang dibutuhkan dalam jam atau hari. Sebuah tim menetapkan poin dengan membandingkannya dengan item referensi yang telah mereka selesaikan, dan poin yang terkumpul per iterasi memberikan dasar untuk memperkirakan berapa banyak pekerjaan di masa mendatang yang dapat diselesaikan.

Abstraksi ini ada karena orang memperkirakan ukuran relatif lebih andal daripada durasi absolut. Ketika ditanya berapa lama sesuatu akan memakan waktu, para penaksir berpegang pada asumsi optimis, mengabaikan gangguan dan pengerjaan ulang, dan menghasilkan angka yang secara konsisten bias ke bawah. Ketika ditanya apakah satu item lebih besar daripada item lainnya, orang yang sama jauh lebih akurat. Sistem poin memanfaatkan asimetri tersebut dengan menangkap perbandingan dan membiarkan hasil yang diamati menyediakan konversi ke waktu.

Poin dimaksudkan untuk mencerminkan kombinasi volume, kompleksitas, dan ketidakpastian, bukan hanya upaya semata. Perubahan kecil pada kode yang tidak dikenal dengan persyaratan yang tidak jelas mungkin lebih besar daripada perubahan ekstensif pada area yang sudah dipahami dengan baik. Tim yang mereduksi poin menjadi sekadar jumlah jam kerja akan kehilangan dimensi ini dan mereproduksi masalah estimasi yang seharusnya dihindari oleh teknik ini.

Ukuran ini bersifat lokal berdasarkan konstruksinya, yang merupakan sifat yang paling sering dilanggar dalam praktiknya. Poin dikalibrasi terhadap item referensi tim tertentu dan mencerminkan konteks, basis kode, dan komposisi tim tersebut. Oleh karena itu, membandingkan total poin antar tim tidak ada artinya, dan menggunakan kecepatan sebagai ukuran produktivitas di seluruh tim secara pasti menghasilkan inflasi estimasi, karena insentifnya adalah untuk memberi skor lebih tinggi pada pekerjaan yang sama.

Distorsi yang sama muncul dalam sebuah tim ketika kecepatan menjadi target. Sebuah tim yang diminta untuk meningkatkan kecepatan dapat melakukannya dengan segera dengan memperkirakan secara lebih optimis, dan angkanya meningkat sementara tidak ada yang berubah. Karena metrik ini mudah dimanipulasi dan dirancang sebagai alat bantu perencanaan daripada ukuran kinerja, penggunaannya dalam pelaporan kinerja menghancurkan kegunaannya untuk tujuan sebenarnya.

Estimasi memiliki biaya nyata yang perlu dicermati. Sesi penyempurnaan dan perencanaan menghabiskan banyak waktu tim, dan untuk pekerjaan dengan distribusi ukuran yang cukup konsisten, manfaat peramalan dibandingkan hanya menghitung item relatif kecil. Tim yang menerapkan pendekatan tanpa estimasi menghitung item yang telah selesai dan melakukan peramalan berdasarkan hasil produksi historis, yang seringkali sama akuratnya dan jauh lebih murah. Apakah estimasi sepadan dengan biayanya adalah pertanyaan yang sah, bukan suatu hal yang dianggap sesat.

Kalibrasi ulang diperlukan setiap kali item referensi berhenti menjadi representatif, yang terjadi seiring dengan kematangan basis kode, perubahan komposisi tim, atau pergeseran sifat pekerjaan. Tim yang menggunakan skala asli selama bertahun-tahun mendapati bahwa poin-poin mereka menggambarkan konteks yang tidak lagi ada, dan perkiraan yang dihasilkan bergeser tanpa ada yang mengidentifikasi penyebabnya.

Poin tetap berguna dalam mengungkap perbedaan pendapat selama estimasi. Ketika anggota tim memberikan nilai yang sangat berbeda untuk item yang sama, diskusi yang menyusul biasanya mengungkapkan bahwa mereka memahami persyaratan secara berbeda, atau bahwa satu orang menyadari adanya komplikasi yang tidak disadari orang lain. Percakapan tersebut seringkali lebih berharga daripada angka yang dihasilkan, yang merupakan argumen untuk mempertahankan diskusi dan bersikap pragmatis tentang perhitungan.

Karena teknik ini hanya berfungsi sebagai alat bantu perencanaan dalam satu tim, nilainya sepenuhnya bergantung pada bagaimana organisasi di sekitarnya menggunakan hasilnya. Dalam praktiknya, praktik estimasi ditetapkan dalam pengembangan produk, dan ketika beberapa tim mengerjakan satu produk, koordinasi akan lebih baik ditangani melalui manajemen ketergantungan dan pengukuran alur di seluruh departemen produk daripada melalui upaya untuk menormalkan perkiraan antar tim.