Prinsip INVEST untuk Membuat User Stories
Selain format yang terstandarisasi dan elemen yang lengkap, sebuah user story juga harus mengikuti INVEST prinsip: 1. Iindependen; 2. Negosiasi; 3. Valutif; 4. Estimasi; 5. Skecil; 6. Tetap.
1. Independen – Penting untuk membuat satu user story seindependen mungkin dari user story lainnya. Mempertahankan independensi antara user story tidak hanya memfasilitasi prioritas dan penyelarasan, membuat perencanaan rilis dan iterasi lebih mudah, memfasilitasi pemahaman, pelacakan, implementasi, pengujian, dan pengiriman yang sering secara independen, tetapi juga membuat ruang lingkup estimasi ukuran user story menjadi lebih jelas dan dengan demikian mengurangi bias estimasi.
2. Negosiasi – Konten dari sebuah user story dapat dinegosiasikan; sebuah user story bukanlah kontrak. Sebuah user story hanyalah deskripsi singkat dari user story tanpa banyak detail; detail spesifik dihasilkan selama fase komunikasi. Sebuah user story dengan terlalu banyak detail sebenarnya membatasi pengguna, ide dan komunikasi tim.
3. Bernilai – Setiap cerita harus bernilai bagi pelanggan (apakah itu pengguna, pembeli, atau peran internal perusahaan). User stories bernilai bagi pengguna akhir, jadi mereka harus ditulis dari perspektif pengguna, menggambarkan FITUR daripada TUGAS.
Fitur ini memfasilitasi pergeseran dari gaya kerja berbasis arahan tradisional ke gaya kerja yang berorientasi nilai yang dipimpin sendiri bagi anggota pengembangan dan pengujian tim, sehingga setiap orang di tim mengetahui nilai dari pekerjaan yang mereka lakukan setiap hari.
4. Dapat diestimasi (dapat dievaluasi) – Bagian yang sangat penting dalam rapat perencanaan adalah estimasi poin cerita. Ini sebenarnya adalah estimasi kasar dari User Story yang akan dikembangkan sehingga tim dapat mengetahui kompleksitas (beban kerja) dari user story ini.
Fokusnya adalah pada apakah user story dapat diselesaikan dalam iterasi saat ini sesuai dengan kondisi penerimaan dari user story tersebut dan DoD (kriteria penyelesaian) yang ditentukan oleh tim, dan jika tidak dapat diselesaikan, alasannya diberikan dan PO memutuskan apakah akan membagi atau merancang ulang user story.
Masalah yang membuat sulit bagi pengembang untuk memperkirakan cerita berasal dari: kurangnya pengetahuan tentang domain (dalam hal ini lebih banyak komunikasi diperlukan), atau cerita terlalu besar (dalam hal ini perlu dipotong menjadi bagian yang lebih kecil).
5.Kecil – Sebuah cerita yang baik harus sesingkat mungkin dalam hal beban kerja, sebaiknya tidak lebih dari 10 orang ideal/hari, setidaknya untuk memastikan bahwa itu diselesaikan dalam satu iterasi. Semakin besar user story, semakin besar risikonya dalam penjadwalan, estimasi beban kerja, dll.
6. Dapat diuji (dapat diuji) – Sebuah user story harus dapat diuji untuk mengonfirmasi bahwa itu dapat diselesaikan. Jika sebuah user story tidak dapat diuji, maka Anda tidak dapat mengetahui kapan itu akan diselesaikan. Contoh user story yang tidak dapat diuji: perangkat lunak harus mudah digunakan.
Tiga Pedoman
Sebuah user story pada dasarnya adalah user story yang baik ketika prinsip INVEST diikuti. Kemudian kita fokus pada tiga pedoman untuk membantu mematuhi prinsip-prinsip tersebut saat menghasilkan user stories.
Tiga pedoman tersebut adalah: satu pengguna, nilai lengkap, dan tanpa ketergantungan.
Satu Tipe Pengguna – Sertakan hanya satu tipe pengguna, karena banyak pengguna sering memiliki nuansa. Biasanya ini adalah pengguna tipikal, sering dengan kebutuhan umum dari suatu jenis.
Nilai Lengkap – Sampaikan nilai pelanggan secara utuh. Sebuah user story yang lengkap berarti bahwa ketika cerita ini selesai, pengguna dapat mencapai tujuan yang jelas dan berarti.
Non-dependency – Tiga jenis ketergantungan yang umum adalah: tumpang tindih, urutan, dan pengandungan.
Secara umum, titik fungsional yang tumpang tindih antara cerita harus dihindari; hubungan berurutan adalah kenyataan dan dapat diselesaikan dengan beberapa cara dalam kebanyakan kasus; dan hubungan inklusi bermanfaat untuk sistem kompleks, dengan implikasi untuk penjadwalan rilis dan rencana iterasi yang perlu diperhatikan.
Ketergantungan yang tumpang tindih
Ketergantungan yang tumpang tindih adalah bentuk ketergantungan yang paling bermasalah, terutama ketika beberapa cerita pengguna mengandung beberapa bagian tumpang tindih yang berbeda. Sulit untuk menemukan satu set cerita pengguna yang dapat mewakili set fitur untuk produk minimum yang layak, yang seharusnya mengandung dan hanya mengandung fitur yang dibutuhkan sekali.
Solusi
Pisahkan bagian yang tumpang tindih sebagai cerita pengguna terpisah.
Pembagian rasional cerita pengguna dan menjaga tumpang tindih hanya dalam satu cerita pengguna yang paling kohesif.
Gunakan model pengembangan Scrum.
Ketergantungan Berurutan
Ketergantungan berurutan berarti bahwa agar sebuah cerita pengguna dapat diselesaikan, satu atau lebih cerita pengguna lainnya harus diselesaikan terlebih dahulu. Ketergantungan berurutan biasanya tidak berbahaya, dan ada cara untuk mengurangi ketergantungan tersebut.
Dari perspektif pengembangan agile, seluruh sistem berkembang secara bertahap dari produk minimum yang layak awalnya menjadi produk yang kuat, dengan setiap langkah berikutnya dibangun di atas langkah sebelumnya.
Tetapi dari perspektif lain, ketergantungan berurutan yang tidak perlu membuat lebih sulit untuk mengurutkan dan memprioritaskan, yang pada gilirannya mempengaruhi pengembangan rencana rilis dan iterasi serta membuat lebih sulit untuk memperkirakan ukuran cerita pengguna.
Solusi
Buat cerita pengguna dalam sebuah iterasi se bebas mungkin dari ketergantungan intrinsik.
Menjaga hanya ketergantungan satu arah antara iterasi, dengan hanya ketergantungan satu arah dalam waktu dari cerita di iterasi yang lebih baru ke cerita di iterasi yang lebih awal (ketergantungan maju).
Menghapus ketergantungan inti sebagai cerita terpisah dan tidak mencampur persyaratan yang bergantung dan tidak bergantung dalam satu cerita.
Inklusi ketergantungan
Ketergantungan yang terkontrol mengacu pada penggunaan manajemen hierarkis dalam mengorganisir cerita pengguna, seperti manajemen fitur-cerita dua tingkat yang umum, di mana sebuah fitur mengandung beberapa cerita pengguna, sehingga membentuk ketergantungan yang terkontrol dari fitur pada cerita bawahannya.
Solusi
Tingkat cerita pengguna digunakan untuk perencanaan iterasi, menghindari perencanaan iterasi yang kasar dengan tingkat fitur, yang dapat digunakan untuk perencanaan rilis.
Tingkat fitur juga dapat dibagi hingga mencapai tingkat fitur yang dapat dipasarkan minimum, dan cerita pengguna yang terkandung di dalamnya dapat dikelompokkan secara terpisah ke dalam fitur yang baru dibagi.
Mengikuti konsep produk minimum yang layak, sebuah fitur diimplementasikan dalam beberapa iterasi dari beberapa cerita pengguna, masing-masing dapat menghasilkan hasil yang potensial atau memberikan umpan balik internal atau eksternal.
Referensi
- Cerita Pengguna yang Efektif – Panduan 3C dan INVEST
- Tema vs Epik vs Cerita Pengguna vs Tugas
- Peta Cerita Pengguna
- Apa itu Pemetaan Cerita Pengguna?
- Tulis Tujuan SMART & INVEST untuk Cerita Pengguna
This post is also available in Deutsch, English, Español, فارسی, Français, 日本語, Polski, Portuguese, Ру́сский, Việt Nam, 简体中文 and 繁體中文.