Cara menulis cerita pengguna yang tangkas: 7 pedoman

Pada dasarnya, cerita pengguna yang tangkas adalah alat yang singkat dan sederhana untuk mendokumentasikan satu tindakan atau niat yang diinginkan oleh pengguna yang ditargetkan untuk mencapai suatu tujuan. Cerita pengguna yang paling sederhana memiliki format, "Sebagai tipe atau peran pengguna , saya ingin bertindak atau berniat  sehingga alasan atau manfaat itu " yang menjawab setidaknya tiga pertanyaan sederhana tentang siapa, apa, dan mengapa cerita tersebut berada dalam antrean backlog.

Saat tim menjadi dewasa dan organisasi menggunakan agile di berbagai tim dan inisiatif, kisah pengguna yang gesit sering kali mengambil lebih banyak definisi dan struktur untuk memastikan ada pemahaman bersama tentang maksud dan persyaratan yang mendasarinya.

Memulai dengan menulis cerita pengguna yang gesit

Ada banyak sumber daya untuk membantu pemilik produk baru, analis bisnis, ahli scrum, dan petunjuk teknis untuk memahami dasar-dasar menulis cerita pengguna. Beberapa tempat untuk memulai termasuk artikel dari Atlassian, FreeCodeCamp, Agile Modeling, dan 200 contoh cerita pengguna ini. Salah satu artikel yang lebih lengkap ada di kisah pengguna tangkas terbaik Alexander Cowan. Ada buku tentang penulisan cerita, termasuk Pemetaan Kisah Pengguna  oleh Jeff Paton dan Peter Economy dan Kisah Pengguna yang Diterapkan  oleh Mike Cohn. Anda juga dapat mengikuti kursus menulis cerita dari Udemy, Learning Tree, VersionOne, dan Lynda.

Salah satu prinsip fundamental yang pertama kali dimiliki oleh Bill Wake adalah berinvestasi dalam cerita-cerita bagus . Invest  adalah singkatan dari "independen, dapat dinegosiasikan, berharga, dapat diperkirakan, kecil, dan dapat diuji," yang merupakan daftar periksa yang baik untuk penulis cerita yang gesit. “Panduan pemimpin yang gesit untuk menulis cerita pengguna” adalah salah satu artikel yang menjelaskan cara menerapkan prinsip investasi  .

Dasar-dasarnya relatif mudah, namun saya sering mendengar dan menyaksikan keterputusan di antara pemangku kepentingan, pemilik produk, pengembang, dan penguji seputar kualitas persyaratan atau apakah sebuah cerita benar-benar selesai. Terkadang ada sudut pandang yang bertentangan tentang tingkat detail yang diperlukan, di mana harus menyesuaikan dengan persyaratan teknis, dan artefak apa yang harus dibuat dengan cerita pengguna.

Dengan mengingat pertanyaan-pertanyaan ini, berikut adalah tujuh pedoman di luar dasar tentang menulis cerita pengguna yang gesit.

1. Tulis cerita untuk audiens yang akan menggunakannya

Sebelum menulis cerita, perlu diingat bahwa cerita dimaksudkan untuk dibaca dan dipahami oleh orang-orang yang berpartisipasi dalam proses pembangunan dengan kebutuhan dan tanggung jawab yang berbeda. Penulis cerita dan kontributor harus memperhatikan audiens dan membuat draf cerita untuk memenuhi kebutuhan kolektif:

  • Pemilik produk mungkin bukan orang yang menulis cerita, terutama jika organisasi Anda mendelegasikan fungsi ini kepada analis bisnis atau jika ada banyak orang yang terlibat dalam penulisan cerita. Pemilik produk ingin memastikan bahwa cerita tersebut sepenuhnya menangkap kebutuhan dan maksud pengguna. Mereka harus membaca kriteria penerimaan secara mendetail tetapi tidak selalu ingin terhambat dengan detail implementasi teknis. Pemilik produk juga harus memahami bagaimana cerita tersebut diselaraskan dengan gambaran yang lebih besar, jadi mereka harus menaruh minat aktif pada bagaimana epos dan fitur didefinisikan dan bagaimana cerita ditugaskan padanya.
  • Pemangku kepentingan tidak akan membaca detail cerita tetapi akan menelusuri dari epos dan membaca ringkasan cerita. Jika Anda memiliki banyak pemangku kepentingan, pertimbangkan untuk menggunakan format deskriptif untuk ringkasan dan pindahkan deskripsi "Sebagai jenis atau peran pengguna " ke awal deskripsi cerita pengguna.
  • Pimpinan teknis sering kali menjadi orang pertama dari tim yang mengulas cerita, dan mereka akan mempelajari persyaratan untuk melihat apakah sebuah cerita terlalu besar dan harus dibagi menjadi beberapa cerita, atau melihat apakah cerita tersebut memerlukan pekerjaan teknis di muka untuk menentukan yang terbaik larutan.
  • Penerima tugas adalah individu yang bertanggung jawab untuk meninjau detail dan melaporkan kemajuan pada rapat standup harian. Petugas harus meninjau cerita untuk dependensi yang mungkin menjadi penghambat selama sprint.
  • Anggota tim sering kali meninjau semua cerita untuk memahami cerita yang ditugaskan kepada mereka dalam konteks cerita lain yang ditugaskan ke sprint.
  • Penguji menentukan apakah ada celah atau risiko yang tidak teridentifikasi dalam kriteria penerimaan dan kemudian mempertimbangkan cara terbaik untuk menerapkannya dalam kerangka pengujian otomatis.
  • Analis tim, yang mungkin adalah manajer program atau anggota kantor manajemen proyek, ingin cerita diberi label dan dikategorikan sepenuhnya sehingga metrik yang berarti dapat ditarik dari backlog.

2. Mulailah dengan mempertimbangkan pengguna

Meskipun cerita pengguna yang gesit mungkin memerlukan banyak detail, sangat penting untuk memulai dengan mempertimbangkan pengguna. Cerita harus mendefinisikan apa  tindakan atau niat pengguna ingin capai dan mengapa  alamat ini kebutuhan, nilai inti, atau tujuan yang berasal dari pengalaman.

Untuk aplikasi yang lebih kompleks, mendefinisikan persona pengguna yang berbeda yang menggambarkan kebutuhan, nilai, dan pola penggunaan dari tipe pengguna yang berbeda merupakan disiplin yang penting dan dapat meningkatkan penulisan cerita. Dalam “10 tip untuk menulis cerita pengguna yang baik,” Roman Pichler menyarankan bahwa “tujuan persona membantu Anda menemukan cerita yang tepat. Tanyakan pada diri Anda sendiri fungsi apa yang harus disediakan oleh produk untuk memenuhi tujuan persona. ” Menggunakan persona untuk memperkuat tujuan pengguna memberikan makna yang lebih kaya tentang mengapa sebuah cerita penting dan membantu memprioritaskan backlog.

3. Jawab mengapa cerita itu penting

Memahami, mendokumentasikan, dan mendiskusikan kebutuhan pengguna atau tujuan persona pengguna hanyalah salah satu dimensi mengapa pemilik produk memprioritaskan cerita. Cerita juga harus memberikan nilai bisnis, sesuatu yang sulit diukur tetapi mungkin memenuhi syarat  pada tingkat cerita, fitur, epik, atau rilis.  

Menjawab alasan  penting bagi pengembang saat mereka diberdayakan untuk mengusulkan opsi penerapan yang berbeda. Misalnya, fitur yang meningkatkan pengalaman masuk bagi pengguna juga dapat menguntungkan bisnis jika pengalaman baru juga menghasilkan data pelanggan yang lebih baik. Pengembang dapat merefleksikan nilai bisnis tambahan ini dan mengoptimalkan penerapan untuk tujuan ini meskipun kriteria penerimaan story tidak spesifik tentang persyaratan ini.

4. Tentukan kriteria penerimaan tanpa meresepkan solusi

Disiplin yang paling penting untuk difokuskan dalam penulisan cerita adalah dalam menyusun kriteria penerimaan. Ini sering berupa daftar poin pernyataan lulus-atau-gagal yang mendokumentasikan persyaratan, batasan, metrik, dan harapan. Kriteria penerimaan ini sering digunakan dalam beberapa cara:

  • Pimpinan teknis dan tim menggunakannya untuk memperkirakan poin cerita berdasarkan kompleksitas dan upaya.
  • Pengembang mempersempit opsi penerapan menjadi opsi yang memenuhi kriteria penerimaan.
  • Pemilik produk dapat mengurangi cakupan atau kompleksitas kriteria penerimaan untuk mendorong penerapan dengan perkiraan yang lebih rendah.
  • Penerima tugas mengomunikasikan blok atau masalah yang memenuhi kriteria sulit selama standup.
  • Insinyur jaminan kualitas menggunakan kriteria penerimaan untuk mengembangkan pengujian otomatis.
  • Pemilik produk meninjau kriteria utama selama demo tangkas untuk memastikan ceritanya selesai .

Kriteria penerimaan menulis bukanlah hal yang sepele. Kriteria penerimaan untuk kriteria penerimaan menyoroti beberapa masalah seperti memberikan terlalu banyak kriteria, mendefinisikan kriteria yang terlalu kabur, atau mendokumentasikan kriteria kompleks yang tidak dapat diverifikasi dengan mudah. Beberapa penulis menggunakan templat kriteria penerimaan yang mendefinisikan struktur untuk kriteria singkat, atom, dan dapat diuji.

5. Gunakan cerita untuk menjelaskan apa dan mengapa; tentukan tugas tentang cara menerapkan

Salah satu kesalahan kritis yang saya lihat dilakukan tim seputar penulisan cerita adalah menjadi verbose dan spesifik di sekitar implementasi. Kisah-kisah yang ditulis dengan buruk ini menginvestasikan banyak upaya untuk menjelaskan bagaimana menerapkannya dengan mengorbankan apa yang dibutuhkan pengguna, mengapa  hal itu memenuhi tujuan mereka, dan di mana  hal itu mendorong nilai bisnis.

Ada beberapa alasan hal ini mungkin terjadi.

Pemilik produk yang tidak berpengalaman dapat menggunakan cerita untuk melukiskan visi implementasi mereka. Dengan kata lain, mereka mungkin terlalu menentukan desain pengguna dan implementasi fungsional daripada berbagi pengalaman dan manfaat pengguna target. Beberapa pemilik produk mengacaukan konseptualisasi mereka tentang bagaimana sesuatu dapat  bekerja (proses yang mereka gunakan untuk memahami persyaratan) dengan bagaimana seharusnya  bekerja, secara tidak sengaja mengubah contoh implementasi internal menjadi spesifikasi implementasi eksternal.

Pemilik produk lain mungkin melangkahi batas mereka dengan meminta tim untuk "membangunkan saya ini". Itu adalah salah satu dari 20 perilaku buruk pemilik produk saya, yang karenanya saya memiliki rekomendasi kepada pemilik produk untuk berkolaborasi dengan tim seputar solusi.

Alasan lain mengapa story menjadi berantakan dengan detail implementasi adalah karena beberapa tim dan pimpinan teknis menginginkan tingkat detail ini. Tim teknis yang baru dibentuk yang bekerja untuk menyempurnakan aplikasi yang ada mungkin menginginkan tingkat detail ini sampai mereka lebih memahami cara kerja aplikasi dan sepenuhnya memahami kebutuhan pengguna. Beberapa tim terdistribusi yang bekerja dengan pengembang lepas pantai atau freelancer mungkin juga ingin mendokumentasikan detail implementasi untuk memastikan anggota ini memahami tanggung jawab mereka.

Untuk tim seperti itu, hal terbaik yang harus dilakukan adalah menautkan ke diagram implementasi dan mendokumentasikan siapa yang melakukan apa dan bagaimana tugas terkait dengan cerita. Sebagian besar alat manajemen tangkas memungkinkan tugas atau subtugas, dan tingkat detail ini biasanya dipisahkan dari badan cerita. Diagram dalam posting ini melakukan pekerjaan dengan baik yang menggambarkan prinsip penting ini menggunakan cerita tangkas untuk memecah pengalaman pengguna dan proses bisnis dan menambahkan tugas untuk menentukan implementasi ke setiap bagian pekerjaan.

6. Tandai cerita Anda untuk mendorong analitik dan mempraktikkan peningkatan

Setelah cerita ditulis, dikerjakan, dan diselesaikan, banyak tim mencari metrik dan melakukan analitik yang dapat mendorong peningkatan proses atau digunakan untuk membuat kasus bisnis untuk investasi tambahan.

Berikut beberapa contohnya:

  • Beri label cerita sebagai hutang teknis untuk mengukur ukuran hutang, persentase kecepatan tim yang digunakan untuk mengatasinya, dan total hutang yang diselesaikan dengan setiap rilis.
  • Tentukan kisah lonjakan fungsional dan teknis untuk mendorong eksperimen dan inovasi, lalu laporkan di mana hal itu berdampak pada bisnis.
  • Jika tim Anda memperkirakan cerita pengguna yang gesit, minta tim untuk menandai cerita di akhir sprint untuk memberi sinyal apakah mereka melebih-lebihkan atau meremehkan untuk meningkatkan keakuratan perkiraan.
  • Gunakan label, komponen, dan bidang kustom untuk membantu pencarian backlog untuk pemahaman atau metrik historis. Misalnya, mengetahui cerita apa yang memengaruhi API atau persyaratan apa yang menyebabkan peningkatan fungsional terakhir ke area tertentu aplikasi dapat dilakukan ketika cerita diberi tag ke komponen fungsional dan teknis.
  • Memberi tag pada cerita yang mengumpulkan atau memproses informasi sensitif seperti informasi identitas pribadi (PII), transaksi e-niaga, atau data yang diatur industri seperti data HIPAA untuk memungkinkan tinjauan keamanan dan kepatuhan.
  • Berikan umpan balik kepada pemilik produk dan tim. Selain menandai cerita sebagai selesai , pemilik produk juga dapat memberikan umpan balik kepada tim seperti mengakui pekerjaan yang bagus . Demikian pula, tim dapat memberikan umpan balik kepada pemilik produk tentang kualitas dan interpretasi keseluruhan cerita pengguna.

7. Tentukan templat cerita tangkas dan panduan gaya

Organisasi yang lebih besar yang bekerja dengan banyak tim gesit dan pemilik produk mungkin ingin menyusun standar dan panduan gaya untuk penulisan cerita. Konsistensi membantu pemilik produk baru mempelajari keterampilan menulis lebih cepat dan juga meningkatkan efisiensi anggota tim dalam mengonsumsi informasi.

Alasan lain untuk mendesain templat cerita adalah bahwa berbagai jenis produk dan aplikasi cocok untuk ekspresi dan artefak cerita pengguna yang berbeda. Beberapa contoh:

  • Kisah proses bisnis mungkin memerlukan link ke diagram alur kerja dan juga menentukan peran dan izin.
  • Kisah aplikasi yang dihadapi pelanggan harus memiliki tautan ke wireframes dan menyertakan kriteria kinerja.
  • Cerita API harus mendokumentasikan pola dan metrik penggunaan yang diharapkan.
  • Kisah intelijen bisnis dan visualisasi data harus memberikan pedoman seputar bidang dan informasi apa yang diperlukan untuk analisis yang diminta.

Template membantu menjembatani komunikasi antara tim dan pemilik produk tentang apa yang harus difokuskan saat menulis cerita yang gesit.

Dan bukankah itu inti dari cerita yang gesit? Praktik, pedoman, dan prinsip penulisan cerita yang tangkas ada untuk membantu tim mengetahui apa yang penting bagi pengguna dan bisnis sebelum mempertimbangkan cara menerapkan.