Panduan Scrum | 20. INVEST – Membuat User Story Terbaik

INVEST adalah metode untuk membuat User Story yang baik. Ini memungkinkan untuk memeriksa apakah mereka memiliki konten yang dirumuskan dengan baik dan apakah mereka terkait dengan nilai bisnis dari Produk. Dan juga, apakah ukuran dan kegunaannya telah dipilih dengan tepat.

Membuat User Story terbaik dengan INVEST – daftar isi:

1. Pendahuluan
2. I untuk Independent
3. N untuk Negotiable
4. V untuk Valuable atau Vertical
5. E untuk Estimable
6. S untuk Small
7. T untuk Testable
8. Ringkasan

Pendahuluan

INVEST adalah akronim yang dibuat oleh Bill Wake pada tahun 2003. Setiap hurufnya mewakili awal dari kata yang menggambarkan sebuah User Story yang baik. Menurut prinsip INVEST, setiap User Story harus:

• Independen
• Negosiasi
• Berharga
• Estimable
• Kecil
• Dapat diuji

Kami menulis lebih banyak tentang apa itu User Story dalam artikel terpisah. Di sini, kami hanya akan menyebutkan bahwa itu adalah deskripsi singkat tentang fungsionalitas Produk baru yang ditulis dalam bahasa yang mudah diakses.

I untuk Independent

Fitur pertama dari User Story yang baik adalah independensinya. Ini berarti bahwa deskripsi dan karakteristiknya harus dipahami tanpa merujuk pada User Story lain. Namun yang paling penting, realizasinya tidak boleh berkorelasi dengan User Story lain. Tentu saja, itu tidak akan sepenuhnya independen. Anda tidak dapat membagi pembuatan Produk menjadi modul yang sepenuhnya terpisah. Namun, sangat penting untuk diingat untuk menjaga User Story tetap seindependen mungkin. Berkat itu, bahkan jika salah satu dari mereka tidak masuk ke fase implementasi atau dimodifikasi secara signifikan, yang lainnya tidak perlu dimodifikasi. Sebagai aturan, User Story harus merupakan keseluruhan yang terpisah dan koheren.

N untuk Negotiable

User Story harus negosiasi. Ini berarti bahwa ia menetapkan Tujuan, bukan cara untuk mencapainya.

Dengan kata lain, ia mendefinisikan fitur yang diharapkan dari Produk, bukan solusi teknis untuk diimplementasikan.

Negosiasi User Story terjadi antara Pemilik Produk dan Tim Pengembangan. Pemilik Produk mengusulkan implementasi fungsionalitas tertentu dari Produk, yaitu mengatakan “Apa” yang harus dilakukan. Para Pengembang bertanggung jawab untuk menjawab pertanyaan “Bagaimana”. Artinya, menegosiasikan cara-cara spesifik untuk menyelesaikan masalah yang disajikan dalam User Story.

V untuk Valuable atau Vertical

Dalam akronim INVEST, huruf V mewakili dua kualitas:

• Berharga
• Vertikal

Keduanya mengungkapkan karakteristik kunci dari User Story yang baik. Oleh karena itu, kami memutuskan untuk menjelaskan apa arti masing-masing.

Berharga

User Story yang berharga membenarkan tujuan bisnis dari modifikasi. Dengan kata lain, ia menjawab dengan tepat pertanyaan mengapa modifikasi tersebut harus diperkenalkan dan mengapa itu penting dari sudut pandang pemangku kepentingan.

Vertikal

Fitur kedua; Vertikal berasal dari metodologi Agile. User Story vertikal mengandung fitur baru dari Produk yang terlihat oleh Pengguna. Artinya, ia tidak fokus pada “perbaikan kinerja” horizontal di lapisan tertentu dari Produk. Sebaliknya, ia menambahkan “lapisan” lain ke dalamnya.

Dengan kata lain, User Story menggambarkan bagaimana memodifikasi operasi keseluruhan dari Produk dengan menjawab pertanyaan Apa yang harus diperbaiki? Ini juga berarti bahwa setiap fungsionalitas dari Produk dibangun di atas solusi yang ada.

E untuk Estimable

User Story yang baik harus dapat diestimasi. Ini berarti bahwa ia harus dengan jelas mendefinisikan ruang lingkup modifikasi yang harus dilakukan pada produk agar User Story dianggap lengkap. Ini memungkinkan Tim Pengembangan untuk menentukan waktu dan usaha yang diperlukan untuk menyelesaikannya.

Ruang lingkup dan kesulitan suatu tugas biasanya diestimasi dalam satuan yang disebut Story Points. Mereka bersifat relatif. Dan setiap Tim Pengembangan bekerja untuk menentukan nilai Story Point dalam praktik berdasarkan pengalaman sebelumnya.

Dalam artikel terpisah, kami telah membahas lebih lanjut tentang Kecepatan Tim Pengembangan dan bagaimana cara mengukurnya.

S untuk Small

User Story yang diterima untuk direalisasikan oleh Tim Pengembangan harus ringkas. Artinya, ia tidak boleh lebih dari satu Sprint. Jika Pengembang menemukan selama Perencanaan Sprint bahwa User Story yang diusulkan oleh Pemilik Produk terlalu panjang, mereka harus membaginya menjadi bagian-bagian yang mungkin independen.

T untuk Testable

Huruf terakhir dari akronim INVEST mewakili dapat diuji. Ini berarti bahwa modifikasi Produk yang dijelaskan dalam User Story harus memiliki bukti dan dapat diverifikasi. Dengan kata lain, harus mungkin untuk memverifikasi apakah solusi yang diimplementasikan oleh Pengembang memberikan nilai yang diharapkan kepada pemangku kepentingan tertentu.

Membuat User Story terbaik – ringkasan

INVEST adalah akronim yang menggambarkan User Story yang ditulis dengan baik. Itu harus:

1. Independen dari User Story lain. Sehingga dapat dimodifikasi atau dihapus dari Product Backlog jika diperlukan.
2. Negosiasi. Itu harus menentukan apa yang harus dilakukan dengan membiarkan pilihan cara melakukannya kepada Pengembang.
3. Berharga, yaitu membenarkan makna bisnis dari modifikasi Produk. Atau Vertikal, yaitu menyajikan fitur baru dari Produk yang terlihat oleh Pengguna.
4. Estimable, yang berarti memiliki ukuran dan kriteria penyelesaian yang dapat didefinisikan.
5. Kecil cukup untuk diselesaikan dalam satu Sprint.
6. Dapat diuji sehingga dapat ditentukan dengan pasti bahwa itu telah diimplementasikan.

Jika Anda menyukai konten kami, bergabunglah dengan komunitas sibuk kami di Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.