User Story adalah teknik yang memungkinkan bisnis untuk memberikan produk dan layanan yang memenuhi kebutuhan pelanggan secara maksimal. Kriteria penerimaan User Story meningkatkan penilaian terhadap fungsionalitas Produk baru dari sudut pandang pengguna.

Kriteria Penerimaan User Story – daftar isi:

  1. Pendahuluan
  2. Bagaimana merumuskan Kriteria Penerimaan User Story?
  3. Kriteria Penerimaan User Story vs. Definisi Selesai
  4. Ringkasan

Pendahuluan

Kami telah membahas User Story dan isu-isu yang perlu ditangani saat pembuatannya di artikel sebelumnya. Namun, hari ini, kami akan fokus pada kriteria penerimaan User Story.

Kriteria penerimaan harus mengikuti pedoman ini:

  • menggambarkan fungsionalitas baru dan yang ditingkatkan dari Produk dari sudut pandang pengguna
  • unik untuk setiap User Story

Panduan Scrum resmi tidak mendefinisikan User Story dan kriteria penerimaannya. Mereka bersifat opsional, tetapi merupakan elemen yang sangat umum dalam pekerjaan Scrum. Namun, untuk mengurangi rasa ingin tahu pembaca kami, kami akan menggambarkannya sebagai: Persyaratan yang harus dipenuhi oleh peningkatan Produk selama Sprint tertentu untuk mendapatkan persetujuan dari Pengguna.

kriteria penerimaan user story

Bagaimana merumuskan Kriteria Penerimaan User Story?

User Story yang ditulis dengan baik mengandung deskripsi yang jelas tentang konteks atau situasi yang dimaksud, sehingga memenuhi kriteria penerimaan. Namun, itu hanya kalimat pendek, terlalu samar dan ambigu untuk secara langsung menunjukkan pertimbangan yang diperlukan.

Kejelasan dan aksesibilitas kriteria penerimaan

Oleh karena itu, untuk mencegah ambiguitas, lakukan dan catat percakapan rinci dengan pelanggan untuk menentukan tujuan dari solusi yang diterapkan. Ingat bahwa perumusan akhir dari kriteria penerimaan adalah milik Pemilik Produk.

Tuliskan mereka bersama dengan kriteria User Story sebelum Perencanaan Sprint. Setiap anggota Tim Scrum harus membacanya dan mengonfirmasi bahwa mereka memahami dan setuju dengan kriteria penerimaan User Story. Biasanya, kriteria penerimaan berada di sebelah lain dari kartu User Story.

Kriteria penerimaan yang dirumuskan dengan baik memungkinkan pengguna untuk memeriksa apakah pengujian User Story mengikuti deskripsinya. Kriteria dapat berupa daftar periksa dengan poin-poin untuk dicentang saat selesai selama pengujian Produk di akhir Sprint.

Masalahnya sederhana jika operasi Produk transparan bagi Pengguna. Namun, semakin kompleks produk, semakin sulit untuk diuji. Ambil perangkat lunak yang kompleks atau layanan berskala besar. Oleh karena itu, dalam banyak kasus, alat yang berguna untuk memvalidasi User Story adalah menyiapkan tes penerimaan.

Tes penerimaan

Jika Anda memutuskan untuk mengembangkan tes penerimaan, tuliskan di sisi lain kartu yang berisi User Story. Nanti, Tim Scrum atau tim QA eksternal dapat melaksanakannya.

Tes harus terlebih dahulu mengandung pernyataan yang jelas tentang apakah Produk gagal atau lulus tes. Itu tidak boleh mengandung pernyataan persentase atau evaluasi sementara.

Jika User Story memiliki lebih dari satu kriteria penerimaan, masing-masing memerlukan pengujian terpisah. Dengan cara ini, jauh lebih mudah untuk menentukan fungsionalitas produk mana yang perlu ditingkatkan atau disempurnakan dan sangat penting jika fungsionalitas baru yang termasuk dalam User Story saling tumpang tindih atau independen satu sama lain.

Kriteria Penerimaan User Story

Kriteria Penerimaan User Story vs. Definisi Selesai

Definisi Selesai adalah bagian integral dari bekerja dalam Scrum, yang merupakan padanan teknis dari kriteria penerimaan. Namun, Anda tidak boleh membingungkan keduanya karena mereka menunjukkan komitmen yang berbeda. Apa itu Definisi Selesai, dan bagaimana serta kapan merumuskannya adalah isu yang telah kami bahas dalam posting terpisah?

Di sini, kami hanya akan menyebutkan bahwa Definisi Selesai adalah deskripsi yang jelas dan transparan tentang keadaan yang diharapkan dari Produk setelah penyelesaian Increment dalam Product Backlog. Ini menggambarkan perbaikan yang dilakukan dalam Increment. Ini bertentangan dengan kriteria penerimaan yang sesuai dengan User Story, yang menggambarkan fungsionalitas Produk yang dibuat selama Sprint terakhir sebagaimana dipersepsikan oleh Pelanggan.

Misalnya, ambil User Story ini dengan konten:

Sebagai pelanggan yang sudah masuk ke dalam toko online, saya ingin membeli tongkat sihir dengan satu klik.

Definisi Penyelesaian untuk User Story di atas mungkin mencakup hal-hal berikut:

  • pembuatan panel login untuk pelanggan toko
  • integrasi sistem pembayaran
  • menambahkan tombol pembayaran instan ke template halaman produk

Di sisi lain, kriteria penerimaan pelanggan mencakup:

  • kemampuan untuk masuk ke toko
  • kemungkinan untuk mendefinisikan metode pembayaran default
  • tombol “Beli sekarang” yang berfungsi untuk produk “tongkat sihir”

Ringkasan

Kriteria penerimaan adalah seperangkat kondisi yang berfungsi sebagai cara untuk mengevaluasi implementasi User Story. Dengan menggambarkan kinerja Produk yang baru dan ditingkatkan dari sudut pandang pengguna, metode ini menjadi alat yang efektif untuk bekerja dengan Pelanggan. Ini menyajikan kinerja Tim Scrum dari sudut pandang pengguna.

Kriteria penerimaan yang dirumuskan dengan baik, misalnya dalam bentuk tes penerimaan, juga memungkinkan kami untuk memeriksa selama Sprint apakah fungsionalitas yang dibuat meningkatkan pemenuhan permintaan Pelanggan.

Kriteria penerimaan berbeda dari Definisi Selesai terutama dalam perspektif yang mereka ambil saat diekspresikan. Mereka tidak mengandung deskripsi tentang persyaratan teknis yang harus dipenuhi oleh solusi baru, tetapi hanya fungsi yang harus dimiliki produk setelah mewujudkan User Story baru.

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

Caroline Becker

Sebagai Manajer Proyek, Caroline adalah ahli dalam menemukan metode baru untuk merancang alur kerja terbaik dan mengoptimalkan proses. Keterampilan organisasinya dan kemampuannya untuk bekerja di bawah tekanan waktu menjadikannya orang terbaik untuk mengubah proyek yang rumit menjadi kenyataan.

View all posts →