Estimasi Sprint yang Lebih Akurat Tanpa Overpromise

Daftar Isi

Kenapa Sprint Planning Sering Meleset?
Tiga Sumber Utama Estimasi yang Salah
Teknik Slicing: Pecah Task Sampai Bisa Selesai 1–2 Hari
Velocity Historis: Pakai Data, Bukan Intuisi
Identifikasi Dependensi Lintas Tim Sebelum Terlambat
Cara Hitung dan Tempatkan Buffer Risiko
Komunikasi Komitmen ke Stakeholder Tanpa Overpromise

Kenapa Sprint Planning Sering Meleset?

Di banyak tim, sprint planning sering berakhir dengan dua skenario yang sama-sama tidak ideal:

Sprint terlalu penuh: di awal terlihat ambisius dan “keren”, tapi di akhir sprint banyak item yang bergeser ke sprint berikutnya.
Sprint terlalu kosong: tim sebenarnya mampu mengerjakan lebih banyak, tapi ragu untuk commit karena trauma “gagal deliver” di sprint sebelumnya.

Akar masalahnya jarang soal kemampuan tim menulis kode. Biasanya sumbernya ada di cara mengestimasi dan membuat komitmen:

Estimasi diberikan terlalu cepat, sering kali di meeting pertama tanpa eksplorasi yang cukup.
Tekanan (eksplisit atau implisit) dari stakeholder membuat tim merasa harus bilang “bisa” walaupun sebenarnya masih banyak ketidakpastian.
Data historis tim tidak dipakai, padahal sudah ada jejak jelas: berapa banyak yang realistis bisa selesai dalam satu sprint.

Akibatnya, sprint planning berubah dari alat untuk mencari kejelasan dan fokus menjadi sesi negosiasi angka. Artikel ini akan fokus ke teknik-teknik praktis agar tim punya:

Task yang cukup kecil dan jelas untuk diestimasi.
Data historis yang dipakai benar-benar sebagai acuan, bukan hanya dekorasi di dashboard.
Ruang untuk risiko dan dependensi sehingga komitmen terasa realistis, bukan sekadar optimisme.

Tiga Sumber Utama Estimasi yang Salah

Task Terlalu Besar dan Abstrak: Estimasi yang diberikan ke task yang masih terlalu besar dan belum jelas scope-nya seringkali meleset karena sulit untuk memprediksi effort yang dibutuhkan. Misalnya, jika kita memberikan estimasi untuk “Buat fitur login” tanpa memecahnya menjadi subtask yang lebih kecil seperti “Desain UI login”, “Implementasi backend login”, dan “Testing login”, kita akan kesulitan untuk memberikan estimasi yang akurat.
Kurangnya Data Historis: Banyak tim yang masih mengandalkan feeling atau intuisi untuk memberikan estimasi, padahal data historis dari sprint sebelumnya bisa digunakan untuk membuat estimasi yang lebih akurat. Tanpa data, kita seperti bermain tebak-tebakan, yang seringkali menghasilkan estimasi yang meleset.
Dependensi yang Tidak Teridentifikasi: Terkadang ada task yang tergantung pada tim lain atau faktor eksternal yang belum diidentifikasi di awal. Ketika ketergantungan ini baru diketahui saat sprint sudah berjalan, itu bisa menyebabkan timeline menjadi berantakan dan estimasi yang diberikan sebelumnya menjadi tidak relevan.

Teknik Slicing: Pecah Task Sampai Bisa Selesai 1–2 Hari

Salah satu sinyal bahwa estimasi akan meleset adalah ketika banyak tiket yang diperkirakan akan selesai dalam 3–5 hari atau lebih. Semakin besar sebuah item, semakin banyak hal tak terduga yang tersembunyi di dalamnya.

Prinsip sederhananya:

Kalau sebuah task tidak bisa selesai dalam 1–2 hari oleh satu orang, berarti task tersebut masih terlalu besar.

Contoh:

Buruk: Implement fitur checkout
Lebih baik di-slice menjadi:
- Desain API dan contract checkout (BE)
- Integrasi payment gateway X
- Validasi address dan shipping option (FE)
- Happy path test & basic error handling

Beberapa teknik slicing praktis yang bisa dipakai:

Slice by workflow: pisahkan tahap “browse → pilih → bayar → konfirmasi” ketimbang “checkout besar 1 paket”.
Slice by risiko: prioritaskan hal yang paling tidak pasti dulu (misalnya integrasi pihak ketiga) daripada polishing UI.
Slice by lapisan: mulai dari contract/API, kemudian skeleton UI, baru kemudian polish dan edge case.

Dengan slicing seperti ini:

Estimasi jadi lebih mudah (karena ruang lingkupnya kecil dan jelas).
Progress sprint lebih kelihatan (lebih sering ada tiket yang “Done”).
Risiko overcommit berkurang, karena item yang “nyangkut” bisa cepat kelihatan sejak awal.

Velocity Historis: Pakai Data, Bukan Intuisi

Velocity adalah jumlah pekerjaan yang benar-benar selesai dalam satu sprint (misalnya dalam satuan story point atau jumlah tiket Done). Kuncinya: velocity harusnya dilihat ke belakang, bukan dinegosiasikan ke depan.

Langkah praktis memakai velocity:

Ambil data 3–6 sprint terakhir dan hitung berapa rata-rata story point yang benar-benar selesai (status Done, bukan “hampir selesai”).
Buang outlier ekstrim (misalnya sprint yang hanya berisi bug kecil karena habis production incident besar).
Gunakan angka rata-rata tersebut sebagai batas atas komitmen sprint berikutnya, lalu turunkan sedikit jika:
- Ada anggota tim yang cuti.
- Ada kegiatan non-feature besar (hackathon, migration, release besar).

Beberapa anti-pattern umum:

Menyetir tim dengan target: “Sprint ini harus 30 poin ya, bulan depan 40 poin.”
Velocity bukan KPI yang perlu “dikejar angkanya”, tapi refleksi kapasitas realistis tim.
Mengubah story point di tengah jalan supaya velocity terlihat bagus.
Ini membuat data historis jadi tidak berguna sama sekali.

Kalau tim konsisten mencatat dan memakai velocity historis, diskusi di sprint planning akan lebih tenang:
“Rata-rata kita 24–26 poin, kondisi sprint ini normal, jadi kita commit 24 poin ya.”

Identifikasi Dependensi Lintas Tim Sebelum Terlambat

Sering kali estimasi sudah cukup rapi, tapi gagal karena ada satu hal: tim lain belum siap. Misalnya:

API dari tim backend belum tersedia.
Approval dari tim legal/compliance terlambat.
Konfigurasi dari tim infra/DevOps baru bisa dilakukan minggu depan.

Cara praktis mengelola dependensi:

Tandai tiket yang punya dependensi eksternal (misalnya dengan label khusus atau prefix di judul).
Di sprint planning, cek satu per satu:
- Apakah dependensi ini sudah benar-benar siap?
- Kalau belum, apa rencana mitigasinya? (misalnya: stub/mock, spike, atau geser ke sprint berikutnya).
Jangan masukkan tiket yang 100% bergantung pada pihak lain yang belum commit timeline jelas. Jika harus masuk, treat sebagai risiko tinggi dan jangan taruh di jalur kritis sprint.

Dengan begitu, estimasi yang diberikan ke tiket bukan hanya soal “berapa lama coding-nya”, tapi juga realistis terhadap dunia nyata yang penuh koordinasi lintas tim.

Cara Hitung dan Tempatkan Buffer Risiko

Tidak ada sprint yang bebas ketidakpastian. Estimasi yang sehat selalu memasukkan buffer untuk:

Hal tak terduga (bug di production, urgent request).
Pekerjaan yang ternyata lebih kompleks dari dugaan awal.

Beberapa pendekatan sederhana:

Buffer persentase:
- Hitung kapasitas berdasarkan velocity historis (misal 24 poin).
- Komit hanya 70–80% dari kapasitas itu untuk work terencana (misal 18–19 poin).
- Sisanya dianggap buffer untuk risiko dan unplanned work.
Buffer eksplisit:
- Buat satu tiket “Buffer / Unplanned Work” dengan story point 3–5.
- Semua unplanned work selama sprint dikaitkan ke tiket ini.

Yang penting: buffer bukan alasan untuk malas atau menutupi estimasi yang buruk, tapi mekanisme sadar untuk mengakui bahwa dunia tidak ideal. Transparansi soal buffer justru meningkatkan kepercayaan stakeholder karena komitmen terdengar masuk akal.

Komunikasi Komitmen ke Stakeholder Tanpa Overpromise

Teknik estimasi yang baik akan percuma kalau cara menyampaikannya ke stakeholder membuat ekspektasi melambung terlalu tinggi. Fokusnya adalah mengkomunikasikan komitmen dengan konteks risiko dan kepercayaan (confidence level).

Beberapa praktik komunikasi yang membantu:

Gunakan rentang, bukan angka tunggal
Alih-alih “Fitur X selesai sprint depan”, gunakan:
“Dengan kapasitas sekarang, kami cukup yakin (±80%) fitur X bisa selesai di antara sprint depan sampai sprint berikutnya.”
Jelaskan asumsi kunci
Misalnya: “Perkiraan ini mengasumsikan tidak ada perubahan prioritas besar dan API dari tim Y tersedia minggu ini.”
Bedakan antara target bisnis dan komitmen tim
Target bisnis boleh ambisius, tapi komitmen tim sebaiknya tetap berangkat dari velocity historis, risiko, dan dependensi yang sudah dipetakan.

Tujuannya bukan supaya semuanya “aman-aman saja”, tapi supaya:

Stakeholder tahu di mana area risiko terbesar.
Tim tidak perlu lagi “janji berlebihan” demi terlihat sanggup.
Ketika ada perubahan di tengah sprint, diskusinya bisa rasional: mana yang harus dikorbankan supaya tetap konsisten dengan kapasitas dan komitmen yang sudah dibuat.

Referensi

Mike Cohn — Agile Estimating and Planning
Scrum Guide 2020 — Scrum.org
Shape Up by Basecamp — Appetite vs. Estimate
Ron Jeffries on Story Points