Kisah Pengguna

User story adalah deskripsi singkat tentang suatu kebutuhan yang diungkapkan dari perspektif orang yang akan mendapatkan manfaat darinya, biasanya ditulis dalam bentuk peran, kemampuan yang diinginkan, dan alasan mengapa hal itu dibutuhkan. Konsep ini muncul dari praktik extreme programming dan menjadi format dominan untuk mengekspresikan pekerjaan dalam pengembangan iteratif.

Tujuan dari mekanisme ini sering disalahpahami. Story bukanlah spesifikasi; melainkan pengingat untuk melakukan percakapan. Rumusan aslinya menggambarkan story sebagai tempat penampung untuk diskusi antara orang-orang yang menginginkan kemampuan tersebut dan orang-orang yang akan membangunnya, dan teks tertulis ada untuk memastikan diskusi terjadi, bukan untuk menggantikannya. Tim yang memperlakukan kartu tersebut sebagai persyaratan lengkap telah mengadopsi format tersebut dan mengabaikan mekanismenya.

Klausul alasan adalah elemen yang membawa nilai paling besar dan yang paling sering ditulis dengan ceroboh. Menyatakan mengapa suatu kemampuan diinginkan memungkinkan tim untuk mengusulkan solusi yang berbeda dan seringkali lebih baik untuk kebutuhan yang sama, dan memungkinkan pekerjaan untuk diprioritaskan ulang secara jujur ​​ketika alasan yang mendasarinya ternyata lemah. Story yang klausul alasannya hanya menyatakan ulang kemampuan tersebut, seperti menginginkan sebuah tombol agar dapat ditekan, tidak mengkomunikasikan apa pun dan menghilangkan kemungkinan percakapan tersebut.

Ukuran sangat penting karena sebuah cerita dimaksudkan untuk dapat diselesaikan dalam satu iterasi dan untuk memberikan sesuatu yang benar-benar dapat dialami pengguna. Cerita yang terlalu besar tidak dapat diselesaikan atau dinilai, sementara cerita yang dipecah menjadi lapisan teknis, seperti membangun tabel basis data atau komponen antarmuka secara terpisah, tidak memberikan apa pun yang dapat diamati secara individual. Pemotongan vertikal, di mana setiap cerita memotong setiap lapisan untuk menghasilkan kemampuan yang tipis namun lengkap, adalah hal yang mempertahankan kemampuan untuk mendemonstrasikan dan belajar.

Format ini merupakan konvensi, bukan persyaratan, dan kepatuhan yang kaku akan menghasilkan hal-hal yang tidak masuk akal. Pekerjaan teknis tanpa pengguna langsung, seperti peningkatan dependensi atau peningkatan kemampuan pengamatan, tidak sesuai dengan templat dan memaksakannya akan menghasilkan pengguna yang dibuat-buat yang menginginkan pembaruan pustaka. Merekam pekerjaan semacam itu secara lugas, dengan alasan yang dinyatakan, lebih jujur ​​dan lebih bermanfaat daripada mendistorsinya untuk memenuhi format.

Kriteria penerimaan adalah hal yang membuat sebuah cerita dapat diuji dan seharusnya menjadi bagian dari cerita itu sendiri, bukan artefak terpisah. Kriteria ini menyatakan kondisi di mana cerita akan dianggap lengkap, termasuk kasus-kasus ekstrem dan jalur kesalahan yang diabaikan oleh bentuk naratif. Tanpa kriteria ini, kelengkapan menjadi masalah opini, dan ketidaksepakatan biasanya muncul saat peninjauan, di mana biaya untuk menyelesaikannya paling mahal.

Cerita-cerita menumpuk menjadi tumpukan yang sulit dikelola jika tidak pernah dipangkas. Artikel yang ditulis beberapa bulan lalu menggambarkan produk dan pasar yang telah berubah, dan tumpukan ratusan cerita adalah dokumen yang tidak dibaca siapa pun, bukan rencana. Menghapus cerita yang secara realistis tidak akan dikembangkan secara berkala memang tidak nyaman, tetapi jauh lebih bermanfaat daripada mempertahankannya tanpa batas waktu.

Karena nilainya bergantung pada percakapan dan bukan pada artefak, efektivitas ditentukan oleh apakah orang yang tepat berpartisipasi. Dalam praktiknya, format ini digunakan dalam pengembangan produk dengan kebutuhan mendasar yang dibuktikan melalui riset pengguna alih-alih diasumsikan, dan organisasi yang membangun kemampuan ini secara internal biasanya menetapkan praktik penulisan dan penyempurnaan di dalam suatu organisasi. departemen produk agar cerita-cerita tersebut berasal dari masalah-masalah yang telah teruji kebenarannya.