Cara Menulis Cerita Pengguna yang Baik dalam Scrum

Sekitar 70% proyek teknologi gagal. Selama beberapa dekade, banyak yang percaya bahwa proyek gagal karena tidak mengikuti praktik terbaik atau karena tim kekurangan keterampilan yang tepat. Namun, adopsi praktik terbaik, keterampilan, dan kompetensi telah meningkat dari waktu ke waktu—lalu mengapa proyek masih gagal?

Mengingat bahwa 70% proyek perangkat lunak gagal karena persyaratan yang buruk. Biaya pekerjaan ulang yang terkait dengan kegagalan ini diperkirakan melebihi 45 miliar dolar AS per tahun.

Do 70% of Your Projects Fail? (Part 1) — Pie

Pertanyaannya adalah—mengapa hal ini terjadi? Jawabannya dua arah. Pertama, persyaratan bisnis sering kehilangan fokus pada pelanggan; kedua, persyaratan tidak memiliki kerangka acuan menyeluruh yang memungkinkan analis persyaratan untuk mengarahkan dan melacak persyaratan dari kebutuhan pelanggan dan strategi hingga solusi yang diimplementasikan.

Untuk menulis persyaratan atau cerita pengguna yang baik, ikuti langkah-langkah berikut:

  1. Tentukan sebanyak mungkin persona untuk mewakili pengguna sistem.Ini akan membantu Anda tetap fokus pada pelanggan dan mengarahkan serta melacak persyaratan berdasarkan kebutuhan pelanggan. Diperkenalkan oleh Alan Cooper, persona mendefinisikan pengguna khas sistem—contoh orang-orang yang berinteraksi dengannya. Pengguna tidak harus atau mewakili individu. Seorang pengguna juga bisa mewakili suatu organisasi.
  2. Pastikan cerita pengguna Anda mengikuti ‘3C’:

Minimum Viable Product Development - Define User Stories - PART 1 - Blog Systango

  • Kartu — Harus ditulis pada kartu indeks atau catatan kecil
  • Percakapan — Dapatkan informasi rinci dari Product Owner
  • Konfirmasi — Pastikan diimplementasikan dengan benar. Harus memenuhi kriteria penerimaan pengguna.
  1. Pisahkan cerita pengguna agar ukurannya sesuai agar muat dalam satu Sprint.Beberapa cara membagi cerita antara lain:
  • Dibagi berdasarkan langkah kerja
  • Dibagi berdasarkan saluran input/keluaran
  • Dibagi berdasarkan pilihan pengguna
  • Dibagi berdasarkan persona/peran
  • Dibagi berdasarkan rentang data
  1. Pastikan setiap cerita pengguna mengikuti mnemonik INVEST:

User stories: a comprehensive guide - Justinmind

Agilemnemonik INVEST, yang dibuat oleh Bill Wake, berfungsi sebagai panduan untuk memastikan Item Backlog Produk (PBIs) berkualitas tinggi, biasanya ditulis dalam format cerita pengguna.

  • Independen: Cerita harus seindependen mungkin.
  • Dapat dinegosiasikan: Cerita bukan kontrak. Cerita adalah undangan untuk berdiskusi. Cerita mencerminkan inti dari apa yang diinginkan.
  • Bermakna: Jika sebuah cerita tidak memiliki nilai yang jelas, maka sebaiknya tidak dilakukan.
  • Dapat Diperkirakan: Sebuah cerita harus dapat diperkirakan atau diukur agar dapat diprioritaskan dengan tepat.
  • Kecil: Untuk iterasi dua minggu, cerita pengguna sebaiknya rata-rata membutuhkan 3–4 hari kerja—total! Ini mencakup semua pekerjaan yang diperlukan untuk membawa cerita ke status ‘Selesai’.Semakin kecil cerita pengguna, semakin tinggi akurasi perkiraan!
  • Dapat Diuji: Setiap cerita harus dapat diuji agar dianggap ‘Selesai’.

Leave a Reply