Hal-Hal Yang Jangan Dilakukan Dengan User Stories
User Stories bukan untuk menuliskan requirement dengan lebih baik, ini untuk menumbuhkan kolaborasi.
Tulisan ini diterjemahkan dari artikel David Pereira yang diterbitkan di Serious Scrum, What Not To Do With User Stories.
Apakah anda tahu bahwa kebanyakan Scrum Team di dunia bekerja menggunakan User Stories? Namun, beberapa miskonsepsi membatasi tim untuk berkembang pesat. David menemukan beberapa pertanyaan yang menggiring tim ke arah yang salah, contohnya:
- Bagaimana saya dapat menulis User Stories yang lebih baik?
- Bagaimana saya dapat memberikan requirement yang lebih detail kepada para developer?
- Bagaimana kita dapat memperoleh estimasi yang lebih baik dengan User Stories?
Sebetulnya, menulis User Stories yang lebih baik bukanlah intinya. Bukan juga mendefinisikan requirement dengan presisi. User Stories adalah tool untuk menumbuhkan kolaborasi dan memastikan kita tidak melupakan bagian paling kritis dari suatu produk atau jasa, yaitu End-User.
David sudah membuat banyak kesalahan saat menggunakan User Stories, tidak terhitung banyaknya. Itulah mengapa ia ingin membagikan kepada anda beberapa pembelajaran, apa yang JANGAN dilakukan dalam menggunakan User Stories.
Belum lama ini, David membagikan video tentang hal-hal yang JANGAN dilakukan dengan User Stories pada kanal YouTube-nya. Jika tertarik, silahkan tonton video berikut.
User Story BUKAN Solusi Untuk Diimplementasikan
Selama bertahun-tahun, David menulis spesifikasi perangkat lunak yang ekstensif. Ia harus memastikan bahwa para developer memiliki semua informasi yang dibutuhkan untuk mengimplementasikan solusi yang dispesifikasikan. Ia tidak terlalu peduli apakah mereka mengerti masalahnya. Mengimplementasikan solusinya dengan benar adalah tujuan utama. Betapapun besarnya usaha kami, para pemangku kepentingan dan para pelanggan tidak puas karena kami gagal memecahkan masalah mereka.
Waktu David mulai bekerja dengan User Stories, ia menyalahgunakannya. Ia berpikir ini adalah tool untuk merepresentasikan requirements. Sebagai Product Owner, ia menulis sebanyak mungkin User Stories. Ini adalah solusi untuk diimplementasikan, gantinya masalah yang butuh dipecahkan. Tetap saja, para pelanggan dan para pemangku kepentingan tidak senang dengan hasilnya.
User stories bukanlah tasks. Faktanya, satu story dapat membutuhkan ratusan tasks satuan agar dapat dihantarkan dengan sukses. Tasks adalah tentang implementasi; user stories adalah tentang definisi.
— George Krasadakis, How (and Why) to Write Great User Stories
David mendapatkan pelajaran penting: jika anda tidak mengubah pola pikir anda, apapun proses atau tool yang anda gunakan, hasilnya akan sama saja. Pertama, anda harus mengubah pola pikir; kemudian, anda akan mendapatkan outcome yang berbeda.
User Stories yang hebat menuntun kepada pembicaraan yang luar biasa. Hasilnya adalah kejelasan bagaimana memecahkan masalah para pengguna.
User Stories yang buruk fokus pada estimasi dari solusi untuk diimplementasikan. Hasilnya hanya suatu estimasi dari solusi untuk diimplementasikan. Masalah sebenarnya tetap tidak diketahui oleh tim.
Jangan Abaikan Pembicaraaan Dengan Tim
Saat ini, kita punya banyak tool untuk mengelola Product Backlog. Antara lain: Jira, Trello, Asana, dan lain-lain. Sangat mudah untuk terjerumus ke banyak lubang. Yang paling sering menjerumuskan adalah membiarkan tools mengatur tindakan kita. Kita harus ingat bahwa tools seperti itu hanyalah alat bantu untuk mencapai tujuan.
“Individu dan interaksi lebih dari proses dan tools”
User Stories diciptakan untuk memecahkan masalah yang serius: memastikan para developer mengerti kebutuhan end-user. Kesederhanaanlah intinya saat Kent Beck menciptakan istilah ini. User Story adalah gabungan dari tiga bagian:
- Kartu (Card): cerita yang dituliskan dari sudut pandang end-user. Siapa, apa, dan mengapa harus jelas. Kartu ini hanyalah pengingat untuk suatu pembicaraan. Anda punya ruang yang terbatas untuk menuliskan hal yang paling penting saja.
- Pembicaraan (Conversation): sebelum mengimplementasi suatu solusi, para developer mengambil kartu dan mendiskusikannya dengan end-user untuk mengerti kebutuhan mereka.
- Konfirmasi (Confirmation): selama pembicaraan, para developer mendefinisikan cara mengkonfirmasi bahwa masalah sudah dipecahkan. Kemudian, mereka menuliskan apa yang diketahui sebagai acceptance criteria.
Demikian cara menggunakan User Stories, namun banyak Scrum Team tidak menjalankannya seperti itu. Skenario yang sering terjadi adalah sebagai berikut:
- Product Owner menuliskan User Story sedetail mungkin ke dalam tool seperti Jira. Acceptance criteria dituliskan dengan presisi.
- Scrum Team menyempurnakan (refines) User Story. Tujuannya untuk mendapatkan kejelasan solusi untuk diimplementasikan. Scrum Team mungkin membentuk kembali acceptance criteria.
- Setelah solusi jelas, para developer mengestimasi User Story.
Bukan demikian cara menggunakan User Stories. Selama Scrum Team belum mengerti masalahnya, mereka belum siap mendiskusikan solusi. Product Owner jangan fokus pada mendefinisikan solusi untuk diimplementasikan; mereka harus fokus pada membangun pemahaman bersama (shared understanding) akan masalah yang patut dipecahkan.
Mulai dengan masalahnya, baru solusi. Bagaimana Product Owner dapat menuliskan semua Acceptance Criteria diawal? Konfirmasi adalah bagian terakhir dari User Stories, seharusnya baru terjadi setelah pembicaraaan dengan tim, bukan sebelumnya.
User stories diciptakan bertahun-tahun yang lalu saat Kent Beck mendefinisikan eXtreme Programming (XP). Tujuannya bukan format aktual tetapi lebih mengarah pada apa maksud di baliknya — yaitu, bercerita. Cerita tentang pelanggan kita, menjelaskan siapa, apa, dan mengapa.
Jangan Memaksakan Semua Dengan User Stories
Walaupun User Stories adalah sesuatu yang sudah diketahui oleh banyak Scrum Team, ini bukanlah keharusan. Anda harus membuat Product Backlog Items dalam format yang terbaik untuk tim anda. Tidak masalah jika menggabungkan User Stories dengan format lainnya.
Jangan terlalu khawatir dengan format Product Backlog Items. Aspek paling penting adalah memastikan ini hanya pengingat untuk suatu pembicaraan. Tolong jangan menganggap Product Backlog Items sebagai requirements, anggap ini sebagai undangan untuk suatu pembicaraan.
Jadi sama sekali tidak ada yang salah dengan User Stories. Ini adalah teknik yang hebat untuk menggambarkan requirement fungsional dengan cara yang “cukup untuk sekarang” — dengan menyediakan ruang untuk pembicaraan lebih lanjut. Tapi Scrum tidak menyarankan ataupun mengharuskannya.
— Christiaan Verwijs, Myth: In Scrum, the Product Backlog has to consist of User Stories
David yakin User Stories bekerja dengan baik saat kita punya masalah untuk dipecahkan atau kesempatan yang menguntungkan. Ini menumbuhkan kolaborasi dan membantu Scrum Team membangun pemahaman bersama yang dibutuhkan untuk maju.
Menurut David, User Stories tidak baik untuk tasks atau bugs. Berdasarkan pengalamannya, tidak cocok untuk menuliskan bugs atau tasks dengan format User Stories. Pendapat David, User Stories tidak dirancang untuk bugs atau tasks. Itulah mengapa memaksakan bugs atau tasks ke dalam User Stories menyebabkan pekerjaan tambahan yang tidak berguna.
Setiap kali anda menjalankan suatu proses secara mekanis, itulah tanda anda harus mempertimbangkannya kembali. Apakah anda mengikuti proses karena sudah terbiasa atau itu adalah cara terbaik untuk mencapai hasil yang anda inginkan?
User Story hanyalah teknik untuk menumbuhkan kolaborasi. Proses ini tidak harus dituruti.
Pemikiran Terakhir
Pola pikir anda adalah aspek paling penting menuju kesuksesan. Jangan fokus pada proses atau tools. Fokus pada membentuk pola pikir anda menjadi seorang dengan dorongan mencapai nilai (value-driven person). Beberapa saran agar User Stories bermanfaat:
- Jangan definisikan solusi untuk diimplementasikan. Fokus pada masalah yang ingin anda pecahkan.
- Jangan terlalu memikirkan detail. Fokus pada pembicaraan dengan tim.
- Solusi ini bukan untuk anda; melainkan untuk end-user.
Jika anda ingin belajar lebih banyak tentang User Stories, David sudah menulis beberapa artikel yang ia rekomendasikan. (Tersedia dalam Bahasa Inggris)
Credits:
- Translated to Indonesian from on David Pereira’s article published in Serious Scrum: What Not to Do With User Stories
