User Story yang menyebalkan
Salah satu artefak penting di dalam Scrum adalah Product Backlog. Product Backlog sendiri dapat disampaikan dengan berbagai hal. Salah satu yang biasa digunakan yaitu User Story/ies. User Story sendiri hadir bukan untuk menggantikan alat bantu pemodelan lain yang bisa bercerita tentang apa yang harus ada di dalam perangkat lunak yang dibangun. Cerita yang terkandung di dalam user story sendiri lebih bermakna dibanding itu karena di dalamnya terdapat semangat setiap orang di dalam tim yang akan dicapai pada setiap sprint yang berjalan.
Format dari user story pun beragam. Saya pribadi sering menggunakan format yang ada pada gambar di bawah ini.
Kalau dilihat dari format tersebut, mungkin yang langsung terbayang di pikiran para software engineer adalah akan sangat mudah mengisi format tersebut. Coba bandingkan dengan format use case scenario yang harus diisi per masing-masing use case.
Belum lagi ketika ada relationship antar use case yang berbanding senilai dengan meningkatnya kerumitan pembuatan use case scenario. Tentunya akan dengan sangat mudah bagi para professional di bidang Software mengatakan “mudah untuk membuat user story”.
Berdasarkan pengalaman saya sendiri dan melihat testimoni dari beberapa pelaku scrum dalam bentuk artikel, membuat user story bisa menjadi hal yang sangat menyebalkan. Menyebalkan karena sulit. Apa sebetulnya kesulitan yang kiranya akan dihadapi dalam membentuk user story? Ini pengalaman saya:
- Kesulitan pertama adalah membentuk pemikiran yang “satu visi dan satu tujuan” di tim scrum. Membentuk user story bukanlah tanggung jawab Product Owner (PO) seorang. Tidak akan baik apabila user story hanya dibentuk oleh satu atau seperbagian tim. Alangkah lebih baik apabila per satuan user story dipahami dan dijiwai oleh setiap individu yang ada pada tim scrum. Yang paling pasti adalah user story yang baik adalah yang terbentuk dari komunikasi yang baik dalam tim.
- Tingkat kedetailan user story yang tidak ada standarnya. Kadang saya dan tim membuat user story yang statementnya tidak terlalu detail yang mengakibatkan muncul banyak pertanyaan maupun persepsi yang berbeda. Tapi terkadang kami membuat user story yang sangat detail dan tentunya memakan waktu yang lama dalam pembahasan per user storynya.
- User Story yang dibuat terkadang sangat product centered sehingga mengakibatkan nilai yang berharga bagi user kita terlupakan. Bahkan terkadang hal ini membuat sebuah user story menjadi tidak bisa dinego (seperti beli barang di bukalapak.com. Brainwash-mu berhasil bukalapak).
Salah satu contohnya adalah user story ini:
As a user, I can easily find events in town so that I can join event that I like.
Statement tersebut pastinya kurang baik karena tidak praktis, tidak teruji, dan sangat susah untuk dibayangkan oleh tim developer (karena pasti banyak timbul pertanyaan dan asumsi). Alangkah lebih baik (belum tentu sangat baik menurut pendapat orang lain) apabila user story-nya dibuat menjadi:
As a user, I can easily find affordable events so that I can pay for join those.
Statement tersebut memiliki kadar pemahaman yang lebih baik, terukur, dan teruji bagi tim developer maupun untuk user yang akan mencoba fungsional tersebut. Minimal dari statement tersebut kita bisa membayangkan akan ada filter untuk menyajikan event berdasarkan range harga event ataupun fungsi sort untuk menyajikan event dari urutan termurah sampai termahal. Selain itu user centered pada statement tersebut lebih terasa.
Adakah tips untuk kita bisa membuat user story agar tidak menjadi user story yang menyebalkan? Jawabannya adalah pengalaman. Pengalaman kita membuat user story bersama dengan tim scrum kita akan membentuk semacam personaliti tim yang makin hari akan makin baik. Common sense tim pun akan semakin terbentuk dan bahkan antar individu di dalam tim tersebut akan menjadi lebih memahami (so sweet!!!). Untuk bisa membentuk pengalaman yang baik maka ada baiknya kita jangan takut terhadap perubahan yang mungkin terjadi pada user story yang kita buat. Mungkin untuk pertama kali user story yang dibuat akan terasa hambar dan ketika diubah, didiskusikan, dan dipahami bersama maka akan terasa makin enak. Ingat, Scrum hadir agar kita terbiasa mengakomodir perubahan dengan cepat, jadi jangan takut akan perubahan itu sendiri. Selain pengalaman, tentunya ada beberapa ukuran (walaupun bukan standarisasi user story) yang bisa dipakai dalam membentuk user story. Ukuran tersebut diantaranya user story harus measureable, testable, user oriented, dan small enough(of course, agar bisa diimplementasi dalam sprint).
So, angkat pantat dari tempatmu duduk sekarang dan mulailah merasakan indahnya membuat user story serta running scrum di timmu.
