Perkiraan dalam pengembangan perangkat lunak sering menjadi sumber ketegangan antara pemilik produk dan tim teknik. Ketika sebuah cerita tidak jelas, pengembang tidak dapat memberikan perkiraan usaha yang akurat. Hal ini menyebabkan perencanaan sprint yang tidak dapat diandalkan, tenggat waktu yang terlewat, dan frustrasi tim. Akar masalahnya jarang karena kurangnya keterampilan teknis; biasanya karena kurangnya kejelasan dalam persyaratan.
Untuk menutup celah ini, cerita pengguna harus ditulis dengan presisi. Mereka harus memberikan konteks yang cukup bagi seorang pengembang untuk memahami apa, mengapa, dan batas-batas pekerjaan. Panduan ini mengeksplorasi cara membuat cerita pengguna yang memfasilitasi perkiraan yang akurat dalam kerangka Scrum, tanpa bergantung pada alat eksternal atau hype.
🤔 Mengapa Perkiraan Gagal
Pengembang tidak memperkirakan waktu; mereka memperkirakan usaha, kompleksitas, dan risiko. Ketika cerita pengguna tidak jelas, variabel yang tidak diketahui akan meningkatkan risiko, yang pada gilirannya meningkatkan perkiraan. Berikut ini adalah alasan umum mengapa cerita sulit diperkirakan:
- Kriteria Penerimaan yang Hilang: Tanpa batas yang jelas, pengembang mengasumsikan skenario terburuk.
- Ketergantungan Teknis: Cerita yang bergantung pada pekerjaan yang belum selesai dari tim lain menciptakan ketidakpastian.
- Kata Kerja yang Samar: Istilah seperti ‘mengoptimalkan’, ‘meningkatkan’, atau ‘memperbaiki’ tidak memiliki hasil yang dapat diukur.
- Pengetahuan yang Diasumsikan: Mengandalkan pengetahuan tribal daripada konteks yang terdokumentasi.
- Terlalu Banyak Cerita: Cerita besar dan monolitik yang mencakup terlalu banyak hal sekaligus.
Ketika seorang pengembang bertanya, ‘Tapi bagaimana persisnya cara kerjanya?’, berarti cerita belum siap untuk diperkirakan. Tujuannya adalah mengurangi kebutuhan akan pertanyaan klarifikasi selama tahap perencanaan sprint.
📐 Model INVEST untuk Cerita yang Dapat Diperkirakan
Model INVEST adalah sebuah mnemonik yang digunakan untuk mendefinisikan cerita pengguna yang baik. Meskipun sering disebutkan, banyak tim mengabaikan aspek Kecil dan Dapat Diuji yang merupakan aspek krusial bagi perkiraan.
1. Independen
Cerita sebaiknya secara ideal bersifat independen. Jika sebuah cerita bergantung pada cerita lain yang harus selesai terlebih dahulu, tim tidak dapat memperkirakannya secara terpisah. Ketergantungan menciptakan hambatan. Jika sebuah cerita benar-benar tergantung, sebaiknya dipecah hingga ketergantungan terselesaikan atau cerita cukup kecil untuk diuji dengan spike.
2. Dapat Dinegosiasikan
Cerita bukan kontrak; mereka adalah tempat penampungan untuk sebuah percakapan. Namun, percakapan harus terjadi sebelum estimasi. Jika sebuah cerita ditulis sebagai spesifikasi tetap tanpa ruang untuk diskusi teknis, hal ini membatasi kemampuan pengembang untuk mengusulkan solusi yang lebih baik yang mungkin memengaruhi perkiraan.
3. Bernilai
Setiap cerita harus memberikan nilai bagi pengguna akhir. Jika sebuah cerita bersifat murni infrastruktur teknis tanpa nilai yang terlihat oleh pengguna, maka ini adalah tugas teknis, bukan cerita pengguna. Tugas teknis membutuhkan pendekatan estimasi yang berbeda dan harus ditangani dengan hati-hati agar tidak membuat sprint menjadi terlalu besar.
4. Dapat Diperkirakan
Ini adalah persyaratan utama untuk panduan ini. Sebuah cerita dapat diperkirakan jika tim memiliki cukup informasi untuk menentukan usaha yang dibutuhkan. Ini berarti:
- Alur pengguna jelas.
- Kebutuhan data telah ditentukan.
- Kasus-kasus tepi telah dipertimbangkan.
- Persyaratan kinerja telah dinyatakan (misalnya, waktu muat).
5. Kecil
Akurasi estimasi menurun seiring dengan meningkatnya ukuran. Cerita yang membutuhkan waktu dua minggu untuk diselesaikan terlalu besar. Harus dibagi menjadi cerita-cerita yang memakan waktu satu hingga tiga hari. Cerita-cerita kecil mengurangi risiko dan meningkatkan tingkat detail dalam estimasi.
6. Dapat Diuji
Jika Anda tidak dapat menulis uji coba untuk cerita ini, Anda tidak dapat menentukan kriteria penerimaan. Jika Anda tidak dapat menentukan kriteria penerimaan, pengembang tidak akan tahu kapan cerita ini selesai. Ini secara langsung memengaruhi estimasi karena ‘selesai’ adalah garis finish.
🛠 Anatomis Cerita Pengguna Berkualitas Tinggi
Cerita pengguna lebih dari sekadar judul. Ini adalah paket informasi. Untuk memastikan pengembang dapat melakukan estimasi secara efektif, setiap cerita harus berisi elemen-elemen berikut.
1. Judul
Judul harus deskriptif namun ringkas. Harus merangkum fungsionalitas utama.
- Buruk:Perbaiki Login
- Bagus:Izinkan pengguna untuk mengatur ulang kata sandi melalui tautan email
2. Pernyataan Pengguna
Format standar adalah: “Sebagai [peran], saya ingin [fitur], agar [manfaat].” Ini memastikan tim memahami konteksnya.
3. Konteks dan Latar Belakang
Pengembang perlu mengetahui konteks bisnis. Mengapa fitur ini dibangun sekarang? Apakah ada persyaratan regulasi? Apakah ini perbaikan untuk bug kritis? Konteks membantu pengembang memprioritaskan keputusan teknis.
4. Kriteria Penerimaan
Ini adalah bagian paling krusial untuk estimasi. Kriteria penerimaan menentukan batas pekerjaan. Harus ditulis dengan cara yang memungkinkan pengujian otomatis.
- Gunakan Diberikan-Jika-Maka:Struktur ini mengurangi ambiguitas.
- Tentukan Kasus Tepi:Apa yang terjadi jika koneksi internet terputus? Apa jika input kosong?
- Tentukan Data:Apakah kita mengambil dari database yang sudah ada? Apakah kita membuat catatan baru?
📋 Perbandingan: Cerita Kabur vs. Cerita Jelas
Memahami perbedaan antara cerita yang menyebabkan kesalahan perkiraan dan yang memfasilitasi kejelasan sangat penting. Tabel di bawah ini menyoroti perbedaan tersebut.
| Fitur | Cerita Kabur (Sulit Diperkirakan) | Cerita Jelas (Mudah Diperkirakan) |
|---|---|---|
| Tujuan | Tingkatkan kinerja dasbor. | Kurangi waktu muat dasbor menjadi di bawah 2 detik untuk 1000 catatan. |
| Cakupan | Optimalkan backend. | Indeks kolom ‘user_id’ di tabel pencarian dan simpan hasil teratas 50 dalam cache. |
| Kriteria Penerimaan | Harus lebih cepat. | 1. Waktu muat < 2 detik. 2. Tidak ada kesalahan pada 1000 catatan. 3. Tampilan mobile berfungsi. |
| Ketergantungan | Tidak ada yang disebutkan. | Membutuhkan akses ke API Analitik yang saat ini dalam tahap beta. |
🧩 Penanganan Ketergantungan dan Risiko
Ketergantungan adalah musuh dari perkiraan. Jika sebuah cerita tergantung pada API tim lain, perkiraannya hanyalah tebakan. Untuk mengurangi risiko ini:
- Identifikasi Sejak Dini: Bahas ketergantungan selama penyempurnaan daftar prioritas, bukan saat perencanaan.
- Buat Cerita Spike: Jika ketergantungan tidak diketahui, buat cerita untuk menyelidikinya. Spike adalah tugas riset dengan batas waktu. Tidak menghasilkan kode, tetapi menghasilkan pengetahuan yang mengurangi risiko.
- Data Tiruan: Jika layanan eksternal tidak tersedia, sepakati struktur respons tiruan. Ini memungkinkan pengembangan berlanjut tanpa terhambat.
- Ketergantungan Eksternal:Jika sebuah cerita bergantung pada layanan pihak ketiga, catat implikasi biaya dan latensi dalam deskripsi.
🗣 Peran Percakapan
Menulis cerita hanyalah separuh pekerjaan. Percakapan adalah separuh lainnya. Cerita yang tertulis adalah pengingat dari percakapan, bukan percakapan itu sendiri.
Penyempurnaan Pra-perencanaan
Sebelum perencanaan sprint, tim harus meninjau daftar backlog. Ini adalah waktu untuk mengajukan pertanyaan. Jika seorang pengembang melihat celah dalam cerita, mereka harus segera menandainya. Cerita yang ditandai selama penyempurnaan adalah cerita yang siap untuk diperkirakan.
Pertanyaan Penjelasan
Selama penyempurnaan, pertanyaan-pertanyaan spesifik harus dijawab. Misalnya:
- Apakah fitur ini perlu dapat diakses?
- Apakah ada protokol keamanan khusus yang diperlukan?
- Berapa jumlah maksimal pengguna yang diharapkan?
- Apakah kita perlu mendukung browser lama?
Jika jawaban-jawaban ini didokumentasikan dalam cerita, perkiraan menjadi lebih dapat diandalkan.
📊 Memahami Teknik Perkiraan
Setelah cerita menjadi jelas, tim membutuhkan metode untuk memperkirakan. Metode itu sendiri kurang penting dibandingkan konsensus yang dibangun.
Poin Cerita
Poin cerita mengukur usaha relatif, kompleksitas, dan risiko. Mereka bukan jam. Menggunakan poin cerita memungkinkan tim fokus pada ukuran pekerjaan, bukan kecepatan individu.
- Kompleksitas:Seberapa sulit logikanya?
- Risiko:Seberapa besar kemungkinannya gagal?
- Usaha:Berapa banyak pekerjaan yang terlibat?
Poker Perencanaan
Ini adalah teknik berbasis konsensus. Setiap pengembang mengangkat kartu dengan angka. Jika angkanya berbeda, pengestimasi tertinggi dan terendah menjelaskan alasan mereka. Ini mengungkap asumsi tersembunyi. Misalnya, satu pengembang mungkin lupa tentang persyaratan integrasi, sementara yang lain menganggap sudah dibangun.
🚫 Kesalahan Umum yang Harus Dihindari
Bahkan dengan niat baik, tim sering terjebak dalam jebakan yang merusak akurasi perkiraan.
1. Hanya Jalur ‘Bahagia’
Menulis cerita yang hanya menggambarkan skenario ideal berbahaya. Pengembang akan memperkirakan berdasarkan jalur bahagia, tetapi pekerjaan sebenarnya mencakup penanganan kesalahan. Selalu sertakan status kesalahan dalam kriteria penerimaan.
2. Mengabaikan Persyaratan Non-Fungsional
Kinerja, keamanan, dan skalabilitas sering diabaikan. Cerita yang mengatakan ‘Buat pengguna’ mungkin membutuhkan 1 poin. Tapi cerita yang mengatakan ‘Buat pengguna yang mendukung 10.000 login bersamaan’ membutuhkan 10 poin. Secara eksplisit nyatakan persyaratan non-fungsional.
3. Terlalu Mengkaji Deskripsi
Jangan menulis spesifikasi teknis dalam cerita pengguna. Pengembang perlu tahu apayang harus dibangun, bukan bagaimanayang harus dibangun. Jika Anda menentukan skema basis data dalam cerita, Anda membatasi kemampuan pengembang untuk memilih solusi terbaik.
4. Melewatkan Definisi Selesai
Definisi Selesai (DoD) berlaku untuk setiap cerita. Ini mencakup pengujian, tinjauan kode, dan dokumentasi. Jika DoD tidak jelas, perkiraan akan salah. Pastikan tim sepakat tentang arti ‘selesai’ sebelum melakukan perkiraan.
🔄 Alur Kerja Proses Penyempurnaan
Untuk menjaga aliran cerita yang dapat diperkirakan secara stabil, ikuti alur kerja ini.
- Draf Awal:Pemilik produk menulis cerita dengan detail dasar.
- Tinjauan Teknis:Pengembang meninjau kelayakan dan kompleksitas tersembunyi.
- Perluasan Kriteria Penerimaan:Tambahkan kasus batas dan keterbatasan.
- Pemeriksaan Ketergantungan:Verifikasi tidak ada penghalang yang ada.
- Perkiraan Akhir:Tim menetapkan poin cerita selama penyempurnaan atau perencanaan.
- Validasi:Pastikan cerita memenuhi kriteria INVEST.
📈 Mengukur Akurasi Perkiraan
Seiring waktu, tim harus melacak akurasi perkiraan mereka. Ini bukan untuk menghukum individu, tetapi untuk memperbaiki proses.
- Pelacakan Kecepatan:Pantau kecepatan tim selama beberapa sprint. Jika kecepatan berfluktuasi secara besar-besaran, kemungkinan cerita tidak konsisten.
- Tingkat Penyelesaian:Apakah tim menyelesaikan semua cerita yang diperkirakan? Jika tidak, apakah mereka terhambat atau diperkirakan terlalu rendah?
- Frekuensi Re-perkiraan:Jika cerita diperkirakan ulang secara sering selama sprint, perkiraan awalnya bermasalah.
🛡 Keamanan dan Kepatuhan
Untuk industri yang diatur, keamanan dan kepatuhan merupakan bagian dari perkiraan. Cerita yang menangani data pengguna membutuhkan usaha yang berbeda dibandingkan cerita yang menampilkan informasi publik. Sertakan pemeriksaan kepatuhan dalam kriteria penerimaan.
- Privasi Data: Apakah cerita ini melibatkan PII (Informasi yang Dapat Mengidentifikasi Pribadi)?
- Jejak Audit: Apakah sistem perlu mencatat siapa yang melakukan perubahan?
- Enkripsi: Apakah data dienkripsi saat disimpan atau saat dalam perjalanan?
Jika persyaratan ini tidak disebutkan, pengembang mungkin membangun solusi yang membutuhkan refaktor besar di kemudian hari, sehingga membuang perkiraan awal.
🧪 Nilai dari Spikes
Kadang-kadang, sebuah cerita terlalu berisiko untuk diperkirakan. Dalam kasus ini, gunakan Spike. Spike adalah investigasi dengan batas waktu. Ini bukan fitur yang dapat dikirim. Ini adalah tugas pembelajaran.
Contoh:
- Cerita: Investigasi kemungkinan integrasi dengan gateway pembayaran lama.
- Tujuan: Menentukan apakah gateway mendukung versi API yang kami butuhkan.
- Output: Dokumen dengan temuan dan rekomendasi.
Setelah spike selesai, cerita fitur sebenarnya dapat diperkirakan berdasarkan temuan. Ini secara signifikan mengurangi risiko.
🤝 Kolaborasi dengan QA
Quality Assurance (QA) harus terlibat dalam proses penyempurnaan. Pengembang mungkin melewatkan kasus-kasus tepi yang ditangkap oleh tester. QA dapat membantu menulis kriteria penerimaan dari sudut pandang pengujian. Ini memastikan cerita benar-benar dapat diuji, yang merupakan komponen kunci dalam perkiraan.
📉 Mengelola Penyebaran Lingkup
Penyebaran lingkup terjadi ketika persyaratan berubah setelah perkiraan. Untuk mencegah ini:
- Kriteria Pembekuan: Setelah diperkirakan, kriteria penerimaan tidak boleh berubah tanpa perkiraan ulang.
- Permintaan Perubahan: Jika perubahan diperlukan, harus dicatat dan ditambahkan ke backlog, bukan dipaksakan ke sprint saat ini.
- Transparansi: Jika perubahan tidak dapat dihindari, segera komunikasikan dampaknya terhadap tujuan sprint.
🧠 Berbagi Pengetahuan
Perkiraan adalah olahraga tim. Pengembang pemula mungkin melakukan perkiraan berbeda dibandingkan dengan yang senior. Untuk menyelaraskan tim:
- Sesi Kalibrasi: Secara rutin tinjau cerita-cerita masa lalu untuk menyelaraskan apa yang dimaksud dengan angka “5” dibandingkan dengan angka “13”.
- Pemrograman Pasangan: Gunakan pemrograman pasangan untuk cerita-cerita kompleks agar bisa berbagi pengetahuan dan mengurangi variasi perkiraan.
- Dokumentasi: Pertahankan perpustakaan cerita-cerita masa lalu sebagai acuan untuk perkiraan di masa depan.
🌟 Pikiran Akhir tentang Kejelasan
Menulis cerita pengguna yang dapat dikalkulasi dengan mudah oleh pengembang adalah latihan empati. Diperlukan dari pemilik produk untuk berpikir seperti insinyur dan memprediksi pertanyaan yang mungkin muncul. Diperlukan dari insinyur untuk bersuara jika informasi tidak lengkap. Ketika kedua belah pihak bekerja sama untuk menghilangkan ambiguitas, perkiraan menjadi alat yang dapat diandalkan untuk perencanaan.
Hasilnya bukan hanya angka yang akurat. Ini adalah kepercayaan. Ketika tim berkomitmen terhadap sekelompok cerita berdasarkan kriteria yang jelas, mereka dapat menghasilkan dengan percaya diri. Fokus berpindah dari menebak-nebak menjadi membangun.
🔑 Poin Utama
- Kejelasan adalah Raja:Cerita yang jelas adalah cerita yang dapat diperkirakan.
- Kriteria Penerimaan: Tentukan batas dan kasus-kasus ekstrem secara eksplisit.
- Ketergantungan: Identifikasi dan kurangi risiko sebelum perencanaan.
- Pembicaraan: Gunakan penyempurnaan untuk membahas detail sebelum melakukan perkiraan.
- Cerita Kecil: Pisahkan pekerjaan besar untuk meningkatkan akurasi.
- Peningkatan Berkelanjutan: Lacak kecepatan dan sesuaikan proses seiring waktu.
Dengan mematuhi prinsip-prinsip ini, tim dapat mengubah perencanaan sprint dari permainan tebak-tebakan menjadi proses yang terstruktur dan dapat diprediksi. Usaha yang diinvestasikan dalam menulis cerita yang baik akan memberi manfaat di setiap sprint berikutnya.