Dalam perencanaan pengembangan perangkat lunak (software development) kita dituntut untuk mampu menyusun requirement dengan tepat dan detail. Tepat dalam menyelesaikan permasalahan pengguna dan detail dalam menyusun alur fitur dengan segala kasus yang terjadi.

Misalkan pada sebuah website ecommerce, pengguna tentu membutuhkan "Fitur Login" untuk bisa mengakses menu di dalam website. Penjelasan "Fitur Login" ini saja masih bias jika tidak di detailkan. Login seperti apa? Menggunakan email atau nomor HP? Kalau nomor HP menggunakan teknologi OTP (One Time Password) atau bagaimana? Bisa login menggunakan sosial media kah, apa saja? dan seterusnya. Disitulah kenapa "Fitur Login" mungkin sudah bisa dibilang requirement yang tepat, namun masih belum detail.

Di beberapa perusahaan software hari ini, sudah cukup familiar dengan istilah User Story. User story sendiri merupakan salah satu tool untuk mendeskripsikan hasil diskusi kita dengan stakeholder, atau dengan kata lain catatan tertulis dari percakapan kita dengan user. Secara teori user story adalah deskripsi singkat fungsionalitas suatu sistem dalam perspektif user (high-level definition). 

Dalam format user story, kita dapat mem-breakdown sebuah fungsionalitas dengan kategori "as" (sebagai siapa); "I want" (saya ingin melakukan apa; dan "so that" (alasan melakukan pekerjaan tersebut, atau bisa juga kita berikan "notes" untuk lebih spesifik menjelaskan kolom "I want". Sebagai contoh:

Sebelum membuat user story, ada beberapa hal yang dapat disiapkan untuk mendapatkan hasil terbaik, yaitu:

1. Banyak-banyak mencoba atau bereksperimen dengan aplikasi atau website yang ada saat ini. Sebagai contoh, ketika ingin membuat user story mengenai e-commerce, kita dapat melakukan benchmarking ke aplikasi atau website e-commerce lain yang ada saat ini.

2. Pastika kita mengetahui siapa saja stakeholder yang terlibat dalam sistem dan role atau peran dari setiap user tersebut seperti apa.

3. Kita harus memahami atribut yang diinginkan user sifatnya statis atau dinamis. Statis dalam artian fitur yang dibuat tidak dapat dimodifikasi atau berubah, sedangkan dinamis maksudnya adalah konten yang ada dalam fitur yang ingin dikembangkan bersifat temporary dan sangat mudah berubah sesuai dengan kebutuhan user. Hal ini akan sangat berpengaruh ke penyusunan database, screen, dan tentunya mandays development.

4. Saat requirement dengan klien, tentukan dan pastikan untuk mengetahui aspek yang di-handle oleh sistem dan yang di-handle di luar sistem.

Bagaimana cara mendefinisikan user story ?

Umumnya, sebelum mem-breakdown user story, kita harus memiliki gambaran mengenai topik dan fitur besar yang ingin dibuat. Adapun penjelasannya dapat dilihat dalam gambar berikut:

EPICS adalah terminologi terkait dengan definisi fitur yang lebih spesifik yang berfungsi untuk menjelaskan gambaran yang lebih detail dari sebuah topics. Topics terdiri dari beberapa EPICS.

User Stories mengacu pada satuan fitur terkecil yang paling spesifik, dan tidak bisa dibagi lagi. EPICS terdiri dari beberapa user story. User story menjelaskan fungsionalitas dalam level paling kecil dalam sebuah software.

Sebuah story bisa jadi memiliki informasi yang masih bias, sebagai contoh: fitur authentication. Jika kita hanya menuliskan ini saja, maka akan ada banyak sekali informasi yang terlewat dan membuat bingung PM atau developer. Sehingga user story ini pun perlu di detailkan lagi dengan lebih spesifik. Ada tiga cara bagaimana mendetailkan user story:

1. Saat requirement gathering atau brainstorming dengan user. Ingatlah bahwa konsep awal story merupakan catatan percakapan dengan user, oleh karena itu kita harus menggali lebih dalam setiap story dari fitur yang ingin dikembangkan. Kita bisa membuat coret-coretan sendiri di kertas untuk menanyakan apa yang user inginkan dalam satu fitur tertentu. Kita juga dapat mengkonfirmasi kriteria yang dibutuhkan dalam satu story sehingga user dapat memvalidasi story yang kita buat benar dan dapat diimplementasikan.

2. Saat perencanaan iterasi. Sebagai bagian dari proses estimasi, adalah hal yang biasa untuk membuat task list yang dibutuhkan untuk mengimplementasi user story.

3. Saat implementasi. Saat Anda membuat user story, Anda mungkin akan membuat semacam gambaran kasar atas apa yang ingin dikembangkan seperti flowchart atau activity diagram yang merepresentasikan kebutuhan bisnis user.  

Berikut ini adalah contoh list user story dengan beberapa elemen didalamnya:  

---

Sebagaimana penjelasan diawal tulisan, bahwa proses mendefinisikan story merupakan fase pertama yang menjadi kunci utama dalam proses development. Namun pada prakteknya pasca requirement gathering, umumnya terdapat beberapa penyesuaian atau perubahan story karena memang mendefinisikan story diawal dengan sangat detail dan presisi serta meng -cover seluruh kebutuhan requirement merupakan hal yang cukup sulit. Belum lagi jika terdapat perubahan requirement dari sisi user pada saat pertengahan development karena merasa ada story yang kurang relevan atau belum tercakup dalam requirement gathering. Oleh karena itu, sebaiknya di awal telah diinformasikan kepada user bahwa requirement gathering pertama hanya mampu memberikan gambaran besar dari proyek yang akan dikerjakan, namun dalam pelaksanaannya sangat mungkin terjadi perubahan sesuai dengan kebutuhan klien.

Referensi:

http://www.agilemodeling.com/artifacts/userStory.htm