Acceptance Criteria (AC), Bagaimana Cara Membuatnya?
Di artikel sebelumnya, saya menjelaskan bahwa salah satu isi dari sebuah Product Requirement Document (PRD) adalah Acceptance Criteria (AC).
Berikut ini adalah beberapa definisi dari AC dalam metodologi agile:
- Kondisi yang harus dipenuhi oleh developer agar produk dapat diterima oleh pengguna, pelanggan, atau stakeholder lainnya. (via Microsoft Press)
- Standar atau persyaratan produk yang harus dipenuhi dan telah ditetapkan sebelumnya. (via Google)
Kesimpulannya, AC biasanya berisi penjelasan requirement dan ruang lingkup yang harus dieksekusi oleh tim developer, untuk menyelesaikan sebuah user story. Penulisan AC ini harus menggambarkan ekspektasi user. Itulah mengapa AC sering juga disebut sebagai definition of done (DoD) dari sebuah user story.
Penulisan AC bisa membantu developer dan stakeholder untuk:
- Mengelola ekspektasi
- Mendefinisikan ruang lingkup dan mengurangi kesalahan persepsi
- Menetapkan kriteria pengujian untuk QA
- Mempertahankan ruang lingkup sprint
Untuk membuat AC, ada beberapa tahapan yang harus saya lalui:
1. Memahami masalah, kebutuhan, dan ekspektasi pengguna
Dalam proses ini, titik mulainya bisa dari beberapa jenis tahapan, misalnya:
- Permintaan stakeholder, karena ada penambahan kebutuhan yang baru.
- Perubahan kebutuhan, biasanya ini dilakukan untuk improvement sebuah fitur.
- Feedback pengguna.
Karena ada perbedaan titik mulai tersebut, maka aksi yang perlu dilakukan pada setiap kasus pun berbeda-beda, bisa berupa Empathise atau Define. Namun, output yang dihasilkan akan selalu sama, yaitu mengatasi masalah yang dialami pengguna.
Nah, di sini bukan peran saya untuk menggali masalah yang dihadapi oleh pengguna, melainkan peran dari UX Researcher. Mereka yang harus menentukan dan melakukan suatu aksi. Setelah UX Researcher melakukan Empathise atau Define, mereka akan menyampaikan hasil-hasil temuannya kepada tim.
Setelah itu, akan ada sesi tanya jawab untuk memperdalam permasalahan yang dihadapi, sampai mendapatkan poin masalah yang perlu diselesaikan. Pada sesi pemaparan dan tanya jawab ini, saya harus benar-benar memahami masalah yang terjadi.
2. Memahami tujuan
Dari inti masalah yang ditemui, saya harus memutuskan tujuan dan arah penyelesaian masalah, agar langkah selanjutnya bisa lebih terarah.
3. Memahami solusi yang diambil
Setelah memahami masalah pengguna dan menentukan tujuan, semua anggota tim akan melakukan ideation. Banyak cara yang dapat dilakukan pada sesi ideation, antara lain:
- Brainstorming
- Brainwriting
- Brainwalk
- Challenge assumptions
- SCAMPER
- MindMap
- Sketchstorm
- Storyboard
- Gamestorming
- Prototype
- Crazy8
Setelah melakukan ideation, ide-ide yang ada akan dikumpulkan, kemudian dikategorikan, disempurnakan, dan dipersempit, sehingga tim dapat memilih solusi yang terbaik. Beberapa metode yang bisa digunakan untuk memilih solusi, yaitu:
- Post-It Voting atau Dot Voting
- Four Categories Method
- Bingo Selection
- Idea Affinity Maps
4. Memahami proses bisnis
Masalah, tujuan, dan solusi yang telah kita ambil harus selaras dengan proses bisnis yang sudah ada. Dengan memahami proses bisnis, kita juga akan menerapkan prosedur yang tepat untuk membuat solusi.
5. Mengumpulkan dan mendokumentasikan semua informasi pendukung
Informasi pendukung merupakan unsur penting untuk membantu kita memprediksi hal apa yang dapat terjadi di kemudian hari, saat kita tengah mengembangkan produk. Informasi-informasi tersebut bisa menjadi acuan jika ada hal-hal yang tidak sesuai dengan ekspektasi kita.
Contoh dokumen pendukung adalah minute of meeting (MoM), dokumentasi Ideation, serta dokumen lain yang bisa diolah (subject/variable).
6. Membuat skenario
Beberapa aktor yang terlibat langsung dalam pembuatan skenario adalah designer, researcher, dan document engineer. Skenario yang dibuat terbagi menjadi dua, yaitu: positive cases dan negative cases.
Isi skenario melingkupi beberapa hal, antara lain:
- Alur sistem
Bagan yang menunjukkan alur kerja atau apa yang sedang dikerjakan di dalam sistem secara keseluruhan, termasuk urutan dari prosedur-prosedur yang ada di dalam sistem. - Behavior design
Penjabaran pola atau aturan dari design itu sendiri. Misalnya search box, saat pengguna memasukkan kata kunci pencarian maka kotaknya tidak memanjang dan placeholder hilang. Sistem kemudian akan melakukan auto search dan menampilkan hasil pencarian. - Validasi
Aturan dari setiap field, termasuk copy handle untuk setiap validasi tersebut. Sebagai contoh, field email akan memiliki validasi seperti ini:
- Tipe data: String
- Harus dalam format email, contoh: xxx@xxx.xx
- Minimal tiga karakter di depan simbol “@”
- Maksimal 50 karakter
- Required (harus diisi)
- Tidak mengandung spasi - Copy Handle Negative case:
- Harus dalam format email, contoh: xxx@xxx.xxx ~> Format email tidak sesuai, contoh: contoh@gmail.com
- Required ~> Email harus diisi
- Maksimal 50 karakter ~> Masukkan email maksimum 50 karakter
7. Finalisasi
Merupakan proses final untuk melakukan pengecekan bersama stakeholder dan tim product lainnya, untuk menyamakan ekspektasi dari fitur yang akan dikembangkan nantinya.
Dalam agile development, AC dibutuhkan sebagai panduan agar developer mengetahui definisi done dari sebuah user story yang akan dikerjakan. Setiap project atau perusahaan bisa memiliki format AC yang berbeda-beda tergantung kebutuhan. Saya akan menjelaskan tentang format tersebut di artikel berikut.
Namun perlu diingat bahwa agile manifesto menyebutkan, “Working Software over Comprehensive Documentation”. Karena itu, sebaiknya jangan sampai pembuatan AC justru memberatkan anggota tim :)
