Cari tahu kenapa Acceptance Criteria itu penting saat membuat user story!

Mungkin terkadang kamu bingung saat membuat user story, dan yang ada malah kamu nggak yakin mau diapakan seterusnya. Pernah mengalami ini? Kalau gitu yuk baca dan pelajari tentang pentingnya acceptance criteria untuk diimplementasikan dalam tim dan user story kamu.

Masalah di atas terjadi saat user story nggak punya acceptance criteria yang jelas. Tapi, apa sih sebenarnya acceptance criteria?

Acceptance criteria adalah susunan kriteria untuk mendefinisikan item produk/ sejumlah persyaratan yang akan diterima oleh Product Owner. Kriteria ini harus didefinisikan dalam user story, harus jelas, dan bisa dipahami oleh tim development. Penerimaan user story dilakukan oleh seorang Product Owner, sesuai dengan acceptance criteria untuk user story tertentu, biasanya bagian dari Definition of Done.

Acceptance criteria diturunkan bersama tim dan Product Owner (setelah P.O. dan tim punya pemahaman yang sama tentang user story­-nya) sebelum implementasi (bukan saat sedang berjalan atau setelahnya).

Ini nih manfaatnya. Dengan acceptance criteria yang jelas dan mudah dipahami, kamu bisa tahu ekspektasimu untuk user story yang bisa menjembatani komunikasimu dengan Product Owner. Sebagai Product Owner, kamu bisa komunikasi lebih baik dengan timmu dan menghasilkan kualitas lebih baik (dan mungkin lebih cepat karena nggak perlu sering dikerjakan ulang karena kurang detail).

Menulis acceptance criteria juga bisa membentuk Batasan di user story: apa yang dimasukkan dan nggak, happy dan unhappy path. Untuk tim teknis, acceptance criteria menjadi basis penulisan tes penerima dan cara otomasi, biasanya menggunakan bahasa Gherkin. 

Mau mulai menulis acceptance criteria?

Yuk, cek tips berikut.

  • Setiap item produk backlog atau user story harus memiliki setidaknya satu acceptance criteria. Lebih baik lagi kalau ada 3-5 poin.
  • Setiap kriteria ada hasil pass/fail yang jelas yang nggak diturunkan dengan rumit dan dengan kalimat panjang.
  • Berfokus pada hasil akhir (apa) dan bukan pendekatan ke solusi (how).
  • Bukan hanya persyaratan fungsional, persyaratan non-fungsional juga dibentuk sebagai acceptance criteria (kalau itu belum jadi bagian dari definition of done).
  • Kalau sudah terlalu besar (satu kriteria terasa seperti sub-story), pertimbangkan untuk membagi user story menjadi berbagai sub-stories.

Yuk, cek juga contoh-contoh acceptance criteria di bawah ini.

Sebagai pengguna, saya dibutuhkan untuk menggunakan password yang kuat saat membuat akun saya.

Acceptance criteria:

  • Harus memiliki minimal 8 karakter
  • Harus mengandung setidaknya 1 digit
  • Harus mengandung setidaknya 1 huruf besar
  • Harus mengandung setidaknya 1 huruf kecil
  • Harus mengandung setidaknya 1 simbol

Kamu bisa cek sumber untuk di atas di sini.

Berikut ini contoh user acceptance criteria di mobile app kita:

Saya, sebagai pengguna yang sudah menandatangani kontrak, melihat ikon Welcome di laman utama, agar saya bisa menjawab sejumlah pertanyaan untuk mengonfirmasi kontrak saya.

Acceptance Criteria:

  1. Pengguna memenuhi syarat H+1 setelah status kontrak aktif
  2. Hanya untuk pelanggan POS offline
  3. Welcome hanya tersedia selama 2 hari sejak pengguna memenuhi syarat

Nah, jangan lupa untuk memastikan kamu punya acceptance criteria yang singkat dan jelas untuk setiap user story kamu. Ini membantu tim untuk merencanakan dan melacak pekerjaan mereka dan membuat user story lebih tepat dan teruji. Lebih dari itu, hal ini juga melatih untuk membentuk pemahaman bersama bukan cuma dengan tim kamu, tapi juga dengan stakeholder.

Kalau kamu butuh bantuan dalam membuat acceptance criteria yang bagus, kontak saja Scrum Master lewat chat atau e-mail ke:

ID.IT.Scrum.Master

it.scrum.smaster@hcg.homecredit.net

Good luck!








Karyawan Kami






Berita