Cara Menulis User Story (dengan Contoh dan Kriteria Penerimaan)
User story adalah deskripsi singkat tentang sebuah fitur dari sudut pandang pengguna: “Sebagai [jenis pengguna], saya ingin [tujuan] agar [alasan].” Di bawahnya Anda menulis kriteria penerimaan, beberapa kondisi spesifik yang harus benar agar story dianggap selesai. Buat setiap story cukup kecil untuk dibangun dan diuji sekaligus, dan tulis kriterianya agar siapa pun bisa memeriksanya.
User story populer di tim perangkat lunak agile, tetapi sama bergunanya saat Anda membangun sendiri dengan AI app builder. Story yang baik adalah prompt yang baik.
Formatnya
Sebuah user story punya tiga bagian:
Sebagai [siapa], saya ingin [apa] agar [mengapa].
- Siapa adalah jenis pengguna yang spesifik: pengunjung baru, member berbayar, resepsionis klinik, admin. Bukan “pengguna”.
- Apa adalah hal yang ingin mereka lakukan, dengan kata-kata mereka sendiri. Bukan cara kerja layarnya.
- Mengapa adalah hasil yang mereka pedulikan. Ini bagian yang sering dilewati, dan yang mencegah Anda membangun hal yang salah.
Contoh:
Sebagai member gym, saya ingin membatalkan pemesanan kelas dari ponsel saya agar seseorang di daftar tunggu bisa mengambil tempat saya dan saya tidak dikenai biaya no-show.
“Mengapa”-nya memberi tahu Anda dua hal yang tidak diberikan “apa”: fitur ini harus berfungsi di ponsel, dan daftar tunggu serta aturan biaya ikut terlibat.
Kriteria penerimaan
Story menyebutkan apa yang diinginkan. Kriteria penerimaan menyebutkan kapan itu selesai. Kriteria harus cukup spesifik sehingga dua orang akan sepakat apakah tiap kriteria lulus.
Cara umum menulisnya adalah Given / When / Then:
- Given (diberikan) situasi awal
- When (ketika) pengguna melakukan sesuatu
- Then (maka) ini hasilnya
Untuk story pemesanan gym tadi:
- Diberikan saya punya pemesanan lebih dari 12 jam lagi, ketika saya mengetuk Batal dan mengonfirmasi, maka pemesanan dihapus dan saya melihat “Pemesanan dibatalkan”.
- Diberikan saya membatalkan pemesanan dan kelasnya punya daftar tunggu, ketika pembatalan tersimpan, maka orang pertama di daftar tunggu mendapat tempat dan email.
- Diberikan pemesanan kurang dari 12 jam lagi, ketika saya mengetuk Batal, maka saya melihat bahwa biaya pembatalan mendadak berlaku sebelum saya mengonfirmasi.
- Diberikan saya berada di layar selebar ponsel, maka tombol Batal terlihat tanpa perlu menggeser ke samping.
Daftar periksa sederhana juga bisa, selama setiap butir bisa diuji. “Membatalkan itu mudah” tidak bisa diuji. “Pembatalan membutuhkan paling banyak dua ketukan dari daftar pemesanan” bisa.
Langkah demi langkah: menulis story yang baik
Langkah 1: Mulai dari pengguna nyata dan masalah nyata
Pilih satu jenis pengguna dan sesuatu yang mereka kesulitkan saat ini. Jika Anda pernah wawancara pelanggan, gunakan kata-kata mereka. “Saya selalu lupa membatalkan dan tetap ditagih” adalah titik awal yang lebih baik daripada “tambahkan fitur pembatalan”.
Langkah 2: Tulis story satu baris
Isi templatnya. Jika Anda tidak bisa menulis bagian “agar” yang meyakinkan, tanyakan apakah fitur ini memang diperlukan.
Langkah 3: Tambahkan tiga sampai enam kriteria penerimaan
Cakup dulu kasus sukses utama, lalu variasi penting: peran lain, kondisi kosong, batasan, atau error. Jika Anda menulis lebih dari enam, story itu kemungkinan terlalu besar.
Langkah 4: Catat apa yang di luar cakupan
Satu baris menghemat banyak bolak-balik: “Di luar cakupan: pengembalian dana untuk kelas berbayar; admin membatalkan atas nama member.” Ini mencegah story membesar saat Anda membangunnya.
Langkah 5: Periksa dengan INVEST
INVEST adalah daftar periksa umum untuk story yang baik. Sebuah story sebaiknya:
| Huruf | Artinya | Tes cepat |
|---|---|---|
| I | Independent (mandiri) | Bisa dibangun tanpa menunggu story lain |
| N | Negotiable (bisa dinegosiasikan) | Menjelaskan kebutuhan, bukan desain yang sudah pasti |
| V | Valuable (bernilai) | Pengguna akan menyadarinya jika dirilis |
| E | Estimable (bisa diperkirakan) | Anda bisa menebak kira-kira seberapa besar |
| S | Small (kecil) | Bisa dibangun dan diuji dalam sekali duduk |
| T | Testable (bisa diuji) | Setiap kriteria penerimaan bisa diperiksa |
Anda tidak perlu memberi nilai pada setiap story. Ini paling berguna saat sebuah story terasa salah dan Anda ingin tahu alasannya.
Contoh yang baik dan buruk
| Story lemah | Masalah | Story yang lebih baik |
|---|---|---|
| Sebagai pengguna, saya ingin dashboard. | Tidak ada pengguna spesifik, tidak ada alasan, tidak bisa diuji | Sebagai pemilik toko, saya ingin melihat pesanan dan pendapatan hari ini dalam satu layar agar saya tahu sekilas apakah hari ini berjalan baik. |
| Sebagai admin, saya ingin database punya kolom status. | Mendeskripsikan implementasi, bukan kebutuhan | Sebagai admin, saya ingin menandai pesanan sebagai sudah dikirim agar pelanggan berhenti mengirim email menanyakan posisi pesanan mereka. |
| Sebagai pelanggan, saya ingin mengelola akun saya. | Terlalu besar: mencakup banyak fitur | Sebagai pelanggan, saya ingin mengubah alamat email saya agar struk masuk ke kotak masuk baru saya. |
| Sebagai pengunjung, saya ingin situsnya cepat. | Ini bukan story; ini kualitas yang dibutuhkan semua orang | Tulis sebagai kriteria di setiap story, atau sebagai target performa tersendiri. |
Cara memecah story yang terlalu besar
Story besar adalah tempat proyek sering macet. Cara umum untuk memecahnya:
- Berdasarkan peran pengguna. Member membatalkan pemesanan mereka sendiri; staf membatalkan pemesanan siapa pun.
- Berdasarkan langkah dalam alur. Menelusuri kelas; memesan kelas; mendapat pengingat.
- Kasus sederhana dulu. Batalkan kelas gratis sekarang; tangani biaya dan pengembalian dana di story berikutnya.
- Berdasarkan variasi data. Dukung satu lokasi dulu, beberapa lokasi nanti.
- Jalur sukses, lalu error. Bangun dulu agar berfungsi, lalu tambahkan penanganan untuk kelas penuh, paket yang kedaluwarsa, dan sebagainya.
Setiap bagian tetap harus sesuatu yang bisa digunakan dan disadari pengguna.
Menggunakan user story sebagai prompt
User story dengan kriteria penerimaan sangat dekat dengan prompt yang baik untuk AI app builder. Ia memberi AI siapa, apa, mengapa, dan definisi selesai. Kirim satu story per pesan:
Sebagai member gym, saya ingin membatalkan pemesanan kelas dari ponsel saya agar seseorang di daftar tunggu bisa mengambil tempat saya. Kriteria penerimaan:
- Batal ada di setiap pemesanan di Pemesanan Saya, dengan langkah konfirmasi.
- Pembatalan lebih dari 12 jam sebelum kelas hanya menghapus pemesanan.
- Kurang dari 12 jam sebelumnya, tampilkan “Biaya pembatalan mendadak sebesar $5 berlaku” sebelum konfirmasi, dan catat biaya itu di pemesanan.
- Jika kelas punya daftar tunggu, orang pertama mendapat tempat dan email.
- Berfungsi di layar selebar ponsel. Di luar cakupan: pengembalian dana, staf membatalkan untuk member. Bangun ini, lalu periksa setiap kriteria di pratinjau dan beri tahu saya mana yang lulus.
Anda juga bisa meminta AI menyusun story dari ide kasar, lalu Anda edit sendiri:
Ini ide aplikasi saya: [dua atau tiga kalimat]. Tulis user story untuk versi pertama, dikelompokkan berdasarkan jenis pengguna, dengan masing-masing 3 sampai 5 kriteria penerimaan Given/When/Then. Tandai mana yang wajib untuk peluncuran dan mana yang bisa menunggu.
Selalu baca dan edit hasilnya. AI tidak mengenal pengguna Anda; Anda yang mengenal.
Kriteria penerimaan juga berfungsi sebagai rencana pengujian Anda. Saat story sudah dibangun, telusuri setiap kriteria sendiri. Panduan kami tentang cara menguji aplikasi sebelum peluncuran dibangun di atas ini.
Di mana user story cocok dengan dokumen lain
- Dokumen kebutuhan produk menjelaskan seluruh produk: masalah, pengguna, cakupan. User story adalah bagian detail di dalamnya. Lihat cara menulis PRD dengan AI.
- Laporan bug menjelaskan sesuatu yang rusak dibandingkan story yang sudah dibangun. Lihat cara menulis laporan bug yang baik.
- MVP adalah kumpulan story terkecil yang memberikan nilai inti. Lihat apa itu MVP.
Kesalahan umum
- “Sebagai pengguna…” Terlalu samar. Sebutkan jenis pengguna yang sebenarnya.
- Melewatkan “agar”. Tanpa alasan, Anda tidak bisa membuat pertukaran yang masuk akal.
- Menulis solusi, bukan kebutuhan. “Saya ingin dropdown” mengunci desain sebelum siapa pun memikirkannya.
- Kriteria yang tidak bisa diuji. “Mudah”, “cepat”, dan “intuitif” adalah harapan, bukan kriteria.
- Story yang sebenarnya adalah epic. “Kelola akun saya” adalah sepuluh story.
- Menulis semua story di awal. Tulis beberapa story berikutnya secara rinci; sisanya cukup satu baris sampai Anda sampai ke sana.
Story di Mythex
Di Mythex, mode Plan adalah tempat yang baik untuk mengubah ide menjadi story: agen membahas pendekatannya sebelum mengedit apa pun. Saat story sudah siap, beralih ke Build dan tempelkan, satu story per pesan. Setelah setiap story, /test bisa mengklik-klik pratinjau dan memeriksa alurnya, dan Anda bisa mengembalikan balasan apa pun dengan Kembali ke titik ini jika hasilnya salah. Lihat prompt yang efektif di dokumentasi, dan panduan kami tentang cara menulis prompt untuk AI app builder.
Daftar periksa user story
- Menyebutkan jenis pengguna yang spesifik
- Mendeskripsikan kebutuhan, bukan desain
- Menyertakan alasan “agar” yang nyata
- Memiliki tiga sampai enam kriteria penerimaan yang bisa diuji
- Mencakup setidaknya satu kasus tepi atau error
- Menyebutkan apa yang di luar cakupan
- Cukup kecil untuk dibangun dan diuji sekaligus
- Kriteria diperiksa satu per satu setelah dibangun
Pertanyaan
Apa format sebuah user story?
Templat yang umum adalah: Sebagai [jenis pengguna], saya ingin [tujuan] agar [alasan]. Setelah itu ada kriteria penerimaan, yaitu daftar singkat kondisi yang harus benar agar story dianggap selesai.
Apa itu kriteria penerimaan?
Kriteria penerimaan adalah kondisi spesifik yang bisa diuji untuk menentukan kapan sebuah user story selesai. Sering ditulis dalam format Given / When / Then: diberikan situasi awal, ketika pengguna melakukan sesuatu, maka hasil tertentu terjadi.
Seberapa besar sebuah user story sebaiknya?
Cukup kecil untuk dibangun dan diuji dalam sekali duduk, namun tetap bernilai dengan sendirinya. Jika sebuah story punya lebih dari lima atau enam kriteria penerimaan atau mencakup beberapa layar, pecah berdasarkan peran pengguna, langkah dalam alur, atau kasus sederhana dulu dan kasus tepi kemudian.
Apakah user story berguna saat membangun dengan AI?
Ya. User story dengan kriteria penerimaan hampir merupakan prompt ideal: ia menyebutkan fitur ini untuk siapa, apa yang mereka butuhkan, dan persis bagaimana memeriksa bahwa itu berfungsi. Mengirim satu story per pesan juga membuat perubahan AI tetap kecil dan mudah diuji.