Panduan Scrum | 21. Kesalahan Cerita Pengguna

Kisah Pengguna menjelaskan cara kerja fungsionalitas Produk baru dalam bahasa sehari-hari atau bisnis. Namun, persiapan mereka membutuhkan banyak waktu, tenaga, dan pemikiran. Dalam entri hari ini, kami menunjukkan kesalahan Kisah Pengguna yang paling umum dan menyarankan cara mengatasinya.

Kesalahan User Story yang paling umum – daftar isi:

1. pengantar
2. Masalah dengan 3W
3. Masalah dengan 3C
4. Kesalahan Cerita Pengguna – Ringkasan

pengantar

Kisah Pengguna dapat menjadi alat yang hebat untuk memotivasi tim untuk mengusulkan solusi baru untuk masalah yang disajikan dari sudut pandang pengguna. Kami menulis tentang apa itu Kisah Pengguna di entri terpisah. Dan dalam artikel ini, kami memperkenalkan INVEST, yang merupakan metode populer untuk menulis Kisah Pengguna yang baik. Hari ini kita akan fokus pada kesalahan User Story.

Masalah dengan 3W

Kisah Pengguna yang tepat menjawab pertanyaan:

• Siapa? (Siapakah target pengguna Produk?)
• Apa? (Kemampuan apa yang dimiliki Produk, dan apa yang dapat dilakukannya?)
• Mengapa? (Tujuan apa yang dilayaninya?)

Namun, masalah mungkin menyertai jawaban untuk setiap pertanyaan ini. Masalah yang paling tidak umum adalah keraguan tentang apa yang harus diubah dalam produk sebagai tanggapan terhadap kebutuhan pelanggan. Oleh karena itu, kami akan fokus pada masalah tentang Siapa? dan mengapa?

Siapa – persona pengguna

Salah satu kesalahan paling umum yang dilakukan saat membuat Cerita Pengguna adalah tidak menjawab pertanyaan dengan cukup tepat: untuk siapa? Dengan kata lain, siapa pengguna untuk siapa perubahan yang direncanakan itu dimaksudkan?

Seringkali tanggapan umum yang menunjuk ke Pelanggan atau Pengguna Akhir sebagai penerima perubahan tidak cukup. Solusi untuk masalah ini adalah membayangkan penerima sebagai persona tertentu. Persona adalah citra model dari target pelanggan. Dengan kata lain, persona adalah representasi dari orang yang akan menggunakan Produk dengan cara tertentu.

Setelah menganalisis Kisah Pengguna Anda, Anda mungkin menemukan bahwa itu menceritakan kisah-kisah orang yang berbeda pada saat yang sama. Jika ada banyak pengguna target, ada baiknya mempertimbangkan untuk membagi Kisah Pengguna menjadi bagian-bagian yang lebih kecil untuk menghindari tindakan yang saling bertentangan, eksklusif, atau tidak efektif.

Mengapa? – tujuan yang didefinisikan dengan buruk

Terkadang bagian terakhir dari Kisah Pengguna menjadi sumber masalah. Itu harus menentukan nilai bisnis dari perubahan yang dibuat selama eksekusi Kisah Pengguna. Lihatlah contoh kesalahan Kisah Pengguna di mana deskripsi fungsi tambahan menggantikan tujuan:

Sebagai pelanggan, saya ingin membeli tongkat ajaib dengan satu klik karena saya ingin membeli karpet terbang minggu depan.

Alih-alih memberikan alasan untuk membeli tongkat ajaib, Kisah Pengguna ini menambahkan item lain ke daftar belanja calon pelanggan. Oleh karena itu, saat menyiapkan Kisah Pengguna, jangan lupakan alasan perubahan fungsi Produk.

Masalah dengan 3C

Kami dapat membagi proses bekerja dengan Cerita Pengguna menjadi tiga tahap yang disebut 3C:

• Kartu – Kartu tempat Kisah Pengguna disimpan
• Percakapan – Percakapan dalam Tim Scrum tentang kartu Cerita Pengguna
• Konfirmasi – mendefinisikan kriteria penerimaan yang mengonfirmasi bahwa tugas telah diselesaikan

Kesalahan dapat terjadi pada salah satu dari ini, yang kami jelaskan di bawah ini.

Kartu

Kartu memori yang menyimpan Kisah Pengguna memiliki kapasitas terbatas. Oleh karena itu, masalah yang paling umum menyangkut panjang dan volume Kisah Pengguna. Kisah Pengguna membutuhkan koherensi dan tidak berbelit-belit, seperti yang mereka katakan, pada tingkat yang tepat sehingga setiap kata diperhitungkan.

Ini karena masalah kartu User Story memiliki dua dimensi. Salah satunya adalah cara merumuskannya: ringkas dan berisi jumlah pencacahan minimum yang diperlukan. Yang kedua adalah ukuran sebenarnya dari Kisah Pengguna. Satu kalimat umum dapat mengungkapkan sejumlah besar tugas yang tidak dapat diselesaikan selama satu Sprint.

Percakapan

Rumusan satu kalimat dari Kisah Pengguna adalah titik awal untuk percakapan dengan Tim Pengembang. Oleh karena itu, tidak tepat untuk memperlakukannya sebagai deskripsi tugas yang harus dilakukan. Ini menonaktifkan kemungkinan negosiasi dan diskusi tentang berbagai cara implementasinya. Kisah Pengguna tidak boleh diperlakukan sebagai deskripsi persyaratan untuk fungsionalitas produk baru, melainkan undangan untuk memulai percakapan tentang solusi teknis tertentu yang akan mengarah pada realisasi nilai bisnis yang ditentukan oleh Kisah Pengguna.

Konfirmasi

Kami menulis tentang kriteria penerimaan yang harus ditentukan untuk setiap Kisah Pengguna secara rinci dalam teks yang menjelaskan apa itu Kisah Pengguna. Namun, salah satu kesalahan umum adalah kurangnya ketidakjelasan kriteria kinerja.

Kisah Pengguna yang ditulis dengan baik berisi deskripsi situasi di mana itu diimplementasikan. Pengujiannya adalah bahwa Pengguna memanfaatkan fungsionalitas baru yang dibuat oleh Tim Pengembang.

Alat yang berguna untuk memvalidasi Kisah Pengguna adalah dengan mengembangkan tes penerimaan. Ini biasanya di sisi lain kartu yang berisi Kisah Pengguna.

Kesalahan Cerita Pengguna – Ringkasan

Saat menyiapkan dan menerapkan Cerita Pengguna, ada baiknya mengikuti aturan berikut:

• Identifikasi dengan tepat Pengguna yang terpengaruh oleh perubahan
• Tentukan dengan jelas tujuan membangun fungsionalitas produk baru
• Jaga Volumenya sesingkat mungkin
• Perlakukan Kisah Pengguna sebagai titik awal untuk diskusi solusi dengan Tim Pengembang
• Tetapkan aturan yang jelas untuk penerimaan

Jika Anda menyukai konten kami, bergabunglah dengan komunitas lebah sibuk kami di Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.

Panduan Scrum:

1. Daftar istilah dasar, peran dan pengertian
2. Apa itu Scrum?
3. Nilai scrum
4. Bagaimana menerapkan Scrum di perusahaan Anda?
5. Tim Scrum - apa itu dan bagaimana cara kerjanya?
6. Siapa Pemilik Produk?
7. Kesalahan paling umum dari Pemilik Produk
8. Siapa Scrum Masternya?
9. Karakteristik Scrum Master yang baik
10. Kesalahan paling umum dari Scrum Master
11. Statistik dan metrik apa yang harus dilacak oleh Scrum Master?
12. Kerjasama antara Pemilik Produk dan Scrum Master
13. Tim Pengembang di Scrum
14. Kesalahan paling umum dari Pengembang
15. Artefak scrum
16. Scaling Scrum
17. Sprint Backlog
18. Apa itu Product Backlog?
19. Apa itu Cerita Pengguna?
20. Membuat Kisah Pengguna terbaik dengan INVEST
21. Kesalahan Cerita Pengguna yang paling umum
22. Kriteria Penerimaan Cerita Pengguna
23. Estimasi dan Poin Cerita di Scrum
24. Perencanaan Poker
25. Game Estimasi Tim
26. Mendefinisikan Kenaikan
27. Acara Scrum
28. Apa itu Sprint di Scrum?
29. Komitmen Tim Scrum - Sasaran Produk, Sasaran Sprint, dan Definisi Penyelesaian
30. Apa itu Grafik Burndown?
31. Bagaimana cara membuat dan menafsirkan grafik burndown?
32. Keuntungan dan kerugian dari grafik burndown
33. Papan Kanban di Scrum dan Scrumban
34. Kecepatan dalam Scrum - Kecepatan Tim Pengembang
35. Scrum Harian
36. Perencanaan Sprint
37. Ulasan Sprint
38. Apa itu Retrospektif Sprint?
39. Kesalahan umum selama Sprint Retrospective
40. Pemeliharaan Backlog Produk