Agile INVEST – 6 Panduan Hebat untuk Cerita Pengguna

Agile menggunakan cerita pengguna untuk mengungkapkan masalah yang harus dipecahkan oleh produk atau sistem. Pedoman Agile INVEST adalah serangkaian rekomendasi yang dikumpulkan oleh Bill Wake untuk membantu menguji dan membuat cerita pengguna berkualitas tinggi (atau secara umum, Item Backlog Produk) yang mendukung manajemen proyek agile yang efektifmanajemen proyek agile.

Menurut Agile INVESTpedoman, cerita pengguna berkualitas tinggi mudah untuk:

• Memahami
• Mengimplementasikan
• Menguji
• Menunjukkan kepada pelanggan
• Bersifat independen

Tapi mari kita uraikan apa sebenarnya makna akronim INVEST.

Agile INVEST – Independen

Ini berarti cerita dapat ada sebagai Item Backlog Produk (PBI) dengan prioritas sendiri, dapat diperkirakan secara independen, dan tidak bergantung pada cerita lain.

Prioritas yang ditetapkan pada cerita pengguna harus menjadi satu-satunya faktor yang menentukan kapan tim mengimplementasikannya. Jika prioritasnya lebih rendah, cerita tersebut berada lebih rendah dalam backlog dan diimplementasikan lebih lambat; jika lebih tinggi, tim akan memindahkannya ke atas dalam backlog untuk pengiriman yang lebih cepat. Ketika cerita pengguna saling tergantung, ketergantungan—bukan prioritas—yang menentukan kapan tim mengimplementasikannya.

Agile INVEST – Dapat dinegosiasikan

Cerita pengguna yang baik menangkap inti kebutuhan pelanggan. Jika ada pertanyaan, tim membahasnya dengan pelanggan untuk menentukan nilai yang tepat dari cerita tersebut. Tim pengembangan dapat bernegosiasi dengan Product Owner dan pemangku kepentingan. Dengan cara ini, kolaborasi antara tim proyek (pemasok dan pelanggan) menciptakan produk atau layanan yang luar biasa.

Apakah tim agile tidak memiliki pertanyaan karena semuanya telah didokumentasikan dalam cerita pengguna agile? Jika demikian, maka seorang analis bisnis yang menulis persyaratan.

Akan ada beberapa item yang tidak dapat dinegosiasikan (sering kali non-fungsional), seperti:

• Kebijakan keamanan terkait akun pengguna
• Persyaratan kinerja, seperti jumlah pengguna bersamaan yang harus ditangani sistem

Itu tidak masalah—selama rincian fungsi itu sendiri tetap terbuka dan mendorong diskusi.

Agile INVEST – Bermakna

Mengacu pada prinsip agile, ‘bermakna’ berarti kita dapat menunjukkan fitur atau fungsi yang diminta kepada pelanggan selama pertemuan Tinjauan Sprint.

Ketika membagi cerita pengguna, tim harus membaginya secara vertikal (juga mewakili huruf ‘V’) daripada secara horizontal. Ini menghasilkan fungsi lengkap pada akhir Sprint dan meningkatkan peningkatan produk yang dapat dikirimkan.

Tim mungkin merasa lebih menarik untuk mengimplementasikan PBI teknis, tetapi mereka tidak selalu memberikan nilai langsung kepada pelanggan—yang bertentangan dengan salah satu prinsip agile: memuaskan pelanggan melalui pengiriman perangkat lunak yang bermakna secara awal dan terus-menerus.

Agile INVEST – Dapat Diperkirakan

Sebuah cerita pengguna yang baik harus dapat diperkirakan. Dalam agile, perkiraan bersifat relatif—dibandingkan dengan cerita pengguna lainnya di backlog. Metode yang populer meliputi urutan Fibonacci, Ukuran kaos (S, M, L, dll.), dan lainnya.

Diskusi mengenai perkiraan membantu seluruh tim mencapai kesepakatan mengenai kondisi yang diperlukan untuk menyelesaikan cerita tersebut. Terkadang sebuah cerita tidak dapat diperkirakan, yang merupakan hal yang wajar jika cerita terlalu besar atau mengandung beberapa fitur dalam satu item. Dalam kasus seperti itu, bagi cerita menjadi beberapa cerita kecil. Dalam situasi lain, terlalu banyak hal yang tidak diketahui sehingga memerlukan penelitian.

Agile INVEST – Kecil

Cerita harus memakan waktu dari beberapa jam hingga maksimal satu periode Sprint penuh. Jika tidak, muncul berbagai masalah—seperti kecepatan (bagaimana tim mempertanggungjawabkan poin pengiriman), kesulitan dalam perkiraan yang akurat, dan sebagainya.

Agile INVEST – Dapat Diuji

Dalam konteks ini, ‘dapat diuji’ mengacu pada kriteria penerimaan yang ditentukan selama analisis.

Kita tidak dapat menganggap sebuah cerita pengguna ‘selesai’ kecuali memenuhi kriteria penerimaan. Satu-satunya cara kita tahu bahwa kriteria tersebut terpenuhi adalah melalui pengujian dan verifikasi.

Kriteria penerimaan bukan merupakan kasus pengujian. Mereka menjawab pertanyaan: ‘Bagaimana saya tahu kapan saya telah menyelesaikan cerita pengguna ini?’

Kasus pengujian menguraikan langkah-langkah yang diperlukan untuk menguji fungsionalitas.

Pelanggan dapat memberi tahu Anda seperti apa lingkungan pengujian dan kondisi pengujian di mana tim menganggap cerita pengguna menjadi SELESAI.