Panduan Scrum | 21. Kesalahan User Story

User Stories menggambarkan bagaimana fungsionalitas Produk baru bekerja dalam bahasa sehari-hari atau bisnis. Namun, persiapannya memerlukan banyak waktu, usaha, dan pemikiran. Dalam entri hari ini, kami menunjukkan kesalahan User Story yang paling umum dan menyarankan cara mengatasinya.

Kesalahan User Story yang paling umum – daftar isi:

1. Pendahuluan
2. Masalah dengan 3W
3. Masalah dengan 3C
4. Kesalahan User Story – Ringkasan

Pendahuluan

User Story bisa menjadi alat yang hebat untuk memotivasi tim untuk mengusulkan solusi baru terhadap masalah yang disajikan dari perspektif pengguna. Kami telah menulis tentang apa itu User Story dalam entri terpisah. Dan dalam artikel ini, kami memperkenalkan INVEST, yang merupakan metode populer untuk menulis User Stories yang baik. Hari ini kami akan fokus pada kesalahan User Story.

Masalah dengan 3W

User Story yang baik menjawab pertanyaan:

• Siapa? (Siapa pengguna target dari Produk?)
• Apa? (Apa kemampuan yang dimiliki Produk, dan apa yang bisa dilakukannya?)
• Kenapa? (Apa tujuan dari hal ini?)

Namun, masalah dapat menyertai jawaban untuk masing-masing pertanyaan ini. Masalah yang paling jarang adalah keraguan tentang apa yang harus diubah dalam produk sebagai respons terhadap kebutuhan pelanggan. Oleh karena itu, kami akan fokus pada masalah yang berkaitan dengan Siapa? dan Kenapa?

Siapa – persona pengguna

Salah satu kesalahan yang paling umum dilakukan saat membuat User Stories adalah tidak menjawab pertanyaan dengan cukup tepat: untuk siapa? Dengan kata lain, siapa pengguna yang dituju oleh perubahan yang direncanakan?

Seringkali, respons generik yang menunjuk pada Pelanggan atau Pengguna Akhir sebagai penerima perubahan tidaklah cukup. Solusi untuk masalah ini adalah membayangkan penerima sebagai persona spesifik. Sebuah persona adalah gambaran model dari pelanggan target. Dengan kata lain, persona adalah representasi dari orang yang akan menggunakan Produk dengan cara tertentu.

Setelah menganalisis User Story Anda, Anda mungkin menemukan bahwa itu menceritakan kisah orang yang berbeda pada saat yang sama. Jika ada banyak pengguna target, ada baiknya mempertimbangkan memecah User Story menjadi fragmen yang lebih kecil untuk menghindari tindakan yang bertentangan, saling eksklusif, atau sekadar tidak efektif.

Kenapa? – tujuan yang tidak terdefinisi dengan baik

Terkadang bagian terakhir dari User Story menjadi sumber masalah. Itu harus menentukan nilai bisnis dari perubahan yang dilakukan selama eksekusi User Story. Lihatlah contoh kesalahan User Story di mana deskripsi fungsionalitas tambahan menggantikan tujuan:

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

Alih-alih memberikan alasan untuk membeli tongkat sihir, User Story ini menambahkan item lain ke daftar belanja pelanggan potensial. Oleh karena itu, saat menyiapkan User Story, jangan lupa tentang alasan untuk perubahan dalam fungsionalitas Produk.

Masalah dengan 3C

Kami dapat membagi proses kerja dengan User Stories menjadi tiga tahap yang disebut 3Cs:

• Kartu – Kartu di mana User Story disimpan
• Percakapan – Percakapan dalam Tim Scrum tentang kartu User Story
• Konfirmasi – mendefinisikan kriteria penerimaan yang mengonfirmasi bahwa tugas telah diselesaikan

Kesalahan dapat terjadi di mana saja dari ini, yang kami jelaskan di bawah.

Kartu

Kartu memori yang menyimpan User Story memiliki kapasitas terbatas. Oleh karena itu, masalah yang paling umum berkaitan dengan panjang dan volume User Story. User Story membutuhkan koherensi dan tidak bertele-tele, seperti yang mereka katakan, hingga tingkat yang tepat di mana setiap kata dihitung.

Ini karena masalah kartu User Story memiliki dua dimensi. Satu adalah cara formulasi: singkat dan mengandung jumlah minimum enumerasi yang diperlukan. Yang kedua adalah ukuran aktual dari User Story. Satu kalimat umum dapat mengekspresikan sejumlah besar tugas yang tidak dapat diselesaikan dalam satu Sprint.

Percakapan

Formulasi User Story dalam satu kalimat adalah titik awal untuk percakapan dengan Tim Pengembangan. Oleh karena itu, tidak benar untuk menganggapnya sebagai deskripsi tugas yang harus dilakukan. Ini menonaktifkan kemungkinan negosiasi dan diskusi tentang berbagai cara pelaksanaannya. User Story tidak boleh diperlakukan sebagai deskripsi persyaratan untuk fungsionalitas produk baru, melainkan sebagai undangan untuk memulai percakapan tentang solusi teknis spesifik yang akan mengarah pada realisasi nilai bisnis yang didefinisikan oleh User Story.

Konfirmasi

Kami telah menulis tentang kriteria penerimaan yang harus didefinisikan untuk setiap User Story secara rinci dalam teks yang menjelaskan apa itu User Story. Namun, salah satu kesalahan umum adalah kurangnya kejelasan kriteria kinerja.

User Story yang ditulis dengan baik mengandung deskripsi situasi di mana ia diterapkan. Ujiannya adalah bahwa Pengguna memanfaatkan fungsionalitas baru yang dibuat oleh Tim Pengembangan.

Sebuah alat yang berguna untuk memvalidasi User Story adalah mengembangkan tes penerimaan. Ini biasanya berada di sisi lain dari kartu yang berisi User Story.

Kesalahan User Story – Ringkasan

Ketika menyiapkan dan menerapkan User Stories, ada baiknya untuk mematuhi aturan berikut:

• Identifikasi dengan tepat Pengguna yang terkena dampak oleh perubahan
• Definisikan dengan jelas tujuan dari pembangunan fungsionalitas produk baru
• Jaga Volumenya tetap sesingkat mungkin
• Anggap User Story sebagai titik awal untuk diskusi solusi dengan Tim Pengembangan
• Tetapkan aturan yang jelas untuk penerimaan

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