Kriteria Penerimaan: Cara Menulisnya (Dengan Contoh)

Kriteria penerimaan adalah kondisi yang harus dipenuhi oleh sebuah cerita pengguna sebelum tim Anda menganggapnya siap untuk dirilis. Tulis dengan benar dan Anda bisa memangkas pengerjaan ulang, perdebatan, serta bug mengejutkan saat waktu tinjauan tiba.

Apa itu kriteria penerimaan?

Kriteria penerimaan adalah sekumpulan kondisi spesifik dan terukur yang dilekatkan pada satu cerita pengguna. Kondisi-kondisi ini mendefinisikan apa yang harus (dan tidak boleh) dilakukan fitur tersebut dari sudut pandang pengguna. Ketika semua kondisi terpenuhi, cerita diterima. Ketika satu kondisi saja gagal, pekerjaan dilanjutkan.

Bayangkan kriteria penerimaan sebagai kontrak antara orang yang meminta fitur dan tim yang membangunnya. Tidak ada tebak-tebakan. Tidak ada "kukira maksudmu sesuatu yang lain." Hanya daftar kondisi lulus-atau-gagal yang ditulis sebelum pengembangan dimulai.

Kriteria penerimaan berada di level cerita. Kriteria ini menjawab pertanyaan: "Bagaimana kita tahu cerita ini selesai?" Itu pertanyaan yang berbeda dari "Bagaimana kita tahu Sprint selesai?" yang dijawab oleh definition of done.

Fakta Utama

• Format Given-When-Then untuk kriteria penerimaan diperkenalkan oleh Dan North sebagai bagian dari behaviour-driven development (BDD) sekitar tahun 2006, memberikan cara yang terstruktur dan terukur bagi tim untuk mengekspresikan perilaku yang diharapkan. (Sumber: Dan North, "Introducing BDD," dannorth.net, 2006.)
• Agile Alliance mencatat bahwa kriteria penerimaan yang ambigu atau tidak ada merupakan salah satu penyebab paling umum dari pengerjaan ulang dalam proyek agile. (Sumber: Agile Alliance Glossary, agilealliance.org.)
• Tim yang menulis kriteria penerimaan sebelum coding melaporkan serah terima yang lebih cepat dari pengembangan ke QA karena penguji sudah tahu apa yang harus diverifikasi.

Format penulisan kriteria penerimaan

Ada dua format yang paling banyak digunakan tim. Tidak ada yang secara universal lebih baik. Pilih yang sesuai dengan cara kerja tim Anda.

Given-When-Then (berbasis skenario)

Juga disebut format Gherkin, format ini berasal dari behaviour-driven development (BDD). Format ini menyusun setiap kondisi sebagai skenario dengan tiga bagian:

• Given -- kondisi awal atau konteks
• When -- tindakan yang dilakukan pengguna
• Then -- hasil yang diharapkan

Contoh -- login pengguna:

Given pengguna terdaftar berada di halaman login
When mereka memasukkan email valid dan kata sandi yang benar lalu klik "Sign In"
Then mereka diarahkan ke dashboard dan melihat pesan selamat datang

Given pengguna terdaftar berada di halaman login
When mereka memasukkan email valid dan kata sandi yang salah
Then mereka melihat pesan error: "Email atau kata sandi tidak benar" dan tetap di halaman login

Format ini cocok ketika perilakunya berurutan dan Anda bisa menulis beberapa skenario kegagalan bersama jalur utama. Engineer QA dapat mengubah setiap skenario langsung menjadi kasus uji.

Berbasis aturan (daftar periksa)

Sebagian tim lebih menyukai daftar poin yang lebih sederhana. Format ini cocok untuk cerita di mana kondisi-kondisinya berdiri sendiri, bukan berurutan.

Contoh -- pencarian produk:

- Hasil pencarian muncul dalam 2 detik untuk kueri apa pun
- Hasil diurutkan berdasarkan relevansi secara default
- Pengguna dapat memfilter hasil berdasarkan kategori, rentang harga, dan penilaian
- Jika tidak ada hasil, halaman menampilkan: "Tidak ada hasil untuk [kueri]. Coba kata kunci yang berbeda."
- Bilah pencarian mempertahankan kueri pengguna setelah hasil dimuat

Kriteria penerimaan berbasis aturan lebih cepat ditulis dan lebih mudah dipindai. Format ini paling baik untuk batasan UI, persyaratan performa, dan kasus tepi yang tidak cocok dengan urutan tindakan pengguna.

Kriteria penerimaan vs definition of done

Dua konsep ini sering dikacaukan. Keduanya memecahkan masalah yang berbeda.

Sebuah cerita bisa melewati semua kriteria penerimaannya namun tetap gagal dalam definition of done, misalnya jika tidak memiliki unit test atau belum ditinjau secara peer review. Kedua daftar harus lolos sebelum pekerjaan benar-benar selesai.

Lihat perbandingan lengkapnya di artikel definition of done.

Karakteristik kriteria penerimaan yang baik

Tidak setiap daftar kondisi memenuhi syarat sebagai kriteria penerimaan yang baik. Inilah yang membedakan yang berguna dari yang kabur:

Dapat diuji. Setiap kondisi harus memiliki hasil lulus atau gagal yang jelas. "UI terlihat bagus" tidak dapat diuji. "Tombol memenuhi rasio kontras 4,5:1" dapat diuji.

Ditulis dari perspektif pengguna. Kriteria penerimaan mendeskripsikan apa yang dialami pengguna, bukan bagaimana kode tersebut disusun. Hindari detail implementasi seperti "API mengembalikan status 200." Lebih baik: "pengguna langsung melihat profil yang sudah diperbarui."

Spesifik. Angka, status, dan label penting. "Respons cepat" menjadi "respons di bawah 1,5 detik." "Sebuah pesan error" menjadi "teks persis: 'Kata sandi harus minimal 8 karakter.'"

Disepakati sebelum pengembangan dimulai. Kriteria yang ditulis setelah fitur dibangun cenderung merasionalisasi apa yang sudah dibuat, bukan mendeskripsikan apa yang dibutuhkan. Tulis kriteria selama backlog refinement.

Tidak terlalu banyak. Tiga hingga delapan kondisi adalah rentang yang sehat. Cerita dengan lima belas kriteria penerimaan kemungkinan besar adalah dua atau tiga cerita yang tersembunyi dalam satu cerita.

Cara menulis kriteria penerimaan

Langkah 1: Mulai dengan cerita pengguna

Anda tidak bisa menulis kriteria penerimaan tanpa cerita pengguna yang jelas. Pastikan Anda memiliki cerita dalam format ini:

Sebagai [persona], saya ingin [tujuan], agar [alasan].

Jika ceritanya kabur, perjelas terlebih dahulu sebelum menulis kondisi.

Langkah 2: Tanyakan "apa yang harus benar agar ini berfungsi?"

Daftarkan perilaku dan hasil yang harus dihasilkan fitur tersebut. Mulai dari jalur utama, lalu kasus tepi dan kondisi kegagalan.

Langkah 3: Pilih format

Pilih Given-When-Then jika perilakunya berurutan dan QA akan mendorong pembuatan uji. Pilih berbasis aturan jika kondisinya berdiri sendiri atau Anda sedang dalam tekanan waktu.

Langkah 4: Tulis dalam bahasa yang dapat diuji

Ganti kata-kata yang kabur. "Dengan cepat" menjadi sebuah angka. "Terformat dengan benar" menjadi format yang tepat. "Harus berfungsi di ponsel" menjadi "tata letak responsif pada lebar 375px."

Langkah 5: Tinjau bersama tim sebelum pengembangan dimulai

Bagikan draf kepada developer, QA, dan pemangku kepentingan. Developer akan menemukan kondisi yang secara teknis tidak mungkin dilakukan. QA akan menemukan kasus tepi yang terlewat. Pemangku kepentingan akan menemukan kesalahan logika bisnis. Lakukan ini selama backlog refinement atau perencanaan sprint agar semua orang selaras sebelum satu baris kode pun ditulis.

Langkah 6: Lampirkan pada cerita

Tambahkan kriteria yang sudah final ke cerita dalam product backlog Anda. Kriteria ini tetap terlampir selama pengembangan berlangsung dan menjadi daftar periksa yang digunakan tim Anda selama tinjauan sprint.

Contoh kriteria penerimaan

Berikut tiga contoh yang sudah dikerjakan untuk berbagai jenis cerita.

Contoh 1: Login pengguna

Cerita: Sebagai pengguna yang sudah kembali, saya ingin masuk dengan email dan kata sandi saya, agar saya bisa mengakses akun saya.

Given pengguna berada di halaman sign-in
When mereka memasukkan email terdaftar dan kata sandi yang benar lalu klik "Sign In"
Then mereka diarahkan ke dashboard dalam 2 detik

Given pengguna memasukkan kata sandi yang salah tiga kali
When mereka mencoba login keempat kalinya
Then akun terkunci selama 30 menit dan pengguna melihat:
"Terlalu banyak percobaan gagal. Coba lagi dalam 30 menit."

Given pengguna sudah masuk
When mereka mengklik "Sign Out"
Then sesi mereka berakhir dan mereka diarahkan ke halaman beranda

Contoh 2: Total pembayaran

Cerita: Sebagai pembeli, saya ingin melihat total pesanan saya sebelum membayar, agar saya tahu persis berapa yang harus dibayar.

Contoh 3: Pencarian tanpa hasil

Cerita: Sebagai pengguna, saya ingin tahu ketika pencarian saya tidak menghasilkan apa-apa, agar saya bisa mencoba kata kunci yang berbeda.

- Ketika pencarian tidak menghasilkan apa pun, halaman menampilkan: "Tidak ada hasil untuk '[kueri]'. Coba kata kunci yang berbeda."
- Bilah pencarian mempertahankan kueri asli pengguna
- Saran kategori terkait muncul di bawah pesan jika tersedia
- Judul halaman diperbarui untuk mencerminkan kondisi pencarian kosong

Kesalahan umum yang harus dihindari

Menulisnya setelah selesai. Kriteria penerimaan yang ditulis pasca-pengembangan mendeskripsikan apa yang sudah dibangun, bukan apa yang dibutuhkan. Tulis terlebih dahulu.

Tidak jelas tentang kondisi error. Kriteria yang hanya mencakup jalur utama membuat developer menebak-nebak penanganan kegagalan. Selalu sertakan setidaknya satu skenario kegagalan.

Mencampurkan detail implementasi teknis. "Layanan memanggil payment API dengan request POST" bukan kriteria penerimaan. "Pengguna melihat konfirmasi pembayaran dalam 3 detik" adalah kriteria yang tepat.

Membuatnya terlalu besar. Jika kriteria penerimaan Anda mencakup beberapa fitur yang berbeda, pecah ceritanya. Cerita yang baik dengan kriteria yang baik muat di sebuah kartu catatan.

Melewati tinjauan tim. Kriteria yang ditulis sendiri (biasanya oleh product owner) melewatkan batasan developer dan kasus tepi QA. Tinjau bersama sebelum Sprint dimulai. Gunakan agile ceremonies seperti refinement untuk melakukan ini secara konsisten.

Pertanyaan yang sering diajukan

Apa itu kriteria penerimaan?

Kriteria penerimaan adalah kondisi spesifik dan terukur yang harus dipenuhi oleh sebuah cerita pengguna sebelum tim menerimanya sebagai selesai. Kriteria ini mendefinisikan apa yang harus dilakukan fitur dari perspektif pengguna, dan ditulis sebelum pengembangan dimulai.

Siapa yang menulis kriteria penerimaan?

Product owner biasanya menyusun draft kriteria penerimaan, tetapi seluruh tim, termasuk developer, QA, dan terkadang pemangku kepentingan, meninjau dan menyempurnakannya sebelum pengembangan dimulai. Menulis kriteria secara terpisah mengarah pada kasus tepi yang terlewat dan pengerjaan ulang.

Apa perbedaan antara kriteria penerimaan dan definition of done?

Kriteria penerimaan bersifat per-cerita: mendeskripsikan apa yang harus dilakukan oleh satu fitur spesifik. Definition of done bersifat global: daftar periksa yang berlaku untuk setiap cerita dalam Sprint (peer review, cakupan uji, dokumentasi, dll.). Sebuah cerita harus melewati keduanya sebelum dirilis.

Apa itu Given-When-Then?

Given-When-Then adalah format terstruktur untuk menulis kriteria penerimaan sebagai skenario yang dapat diuji. "Given" menetapkan konteks, "When" mendeskripsikan tindakan pengguna, dan "Then" menyatakan hasil yang diharapkan. Format ini diperkenalkan oleh Dan North sebagai bagian dari behaviour-driven development (BDD) sekitar tahun 2006 dan banyak digunakan dalam tim agile saat ini.

Berapa banyak kriteria penerimaan yang harus dimiliki sebuah cerita pengguna?

Targetkan tiga hingga delapan. Kurang dari tiga sering berarti ceritanya kurang dispesifikasi. Lebih dari delapan biasanya berarti ceritanya terlalu besar dan harus dipecah menjadi cerita-cerita yang lebih kecil.

---

Kriteria penerimaan yang baik tidak menjamin produk yang hebat, tetapi mencegah kategori kegagalan tertentu: membangun sesuatu yang tidak pernah dimaksudkan oleh siapa pun. Tulis lebih awal, tinjau bersama, dan Anda akan menemukan tinjauan sprint Anda berubah dari perdebatan tentang arti "selesai" menjadi demonstrasi perangkat lunak yang berjalan dengan mulus.