Bahasa Indonesia

User Stories: Cara Menulisnya (Beserta Contoh dan Template)

Anatomi template user story dengan peran, tujuan, dan manfaat

User stories adalah deskripsi singkat dalam bahasa sederhana tentang sebuah fitur yang diceritakan dari sudut pandang orang yang akan menggunakannya. Ini adalah tulang punggung sebagian besar Backlog agile dan Scrum, dan ketika ditulis dengan baik, user stories membuat tim pengembangan tetap fokus pada outcomes pengguna yang nyata alih-alih persyaratan teknis yang abstrak.

Apa Itu User Stories?

User story adalah deskripsi singkat dan informal tentang fitur perangkat lunak dari sudut pandang pengguna akhir. Ini bukan spesifikasi teknis. Ini adalah penanda untuk percakapan tentang apa yang dibutuhkan pengguna dan mengapa kebutuhan itu penting bagi produk.

Istilah ini mulai digunakan secara luas melalui Extreme Programming (XP) pada akhir 1990-an dan kemudian dikodifikasi oleh Mike Cohn dalam bukunya tahun 2004 User Stories Applied. Saat ini, user stories adalah praktik standar di seluruh tim agile, dari startup dua orang hingga divisi produk enterprise.

User stories membuat tim jujur. Alih-alih membangun fitur karena terdengar menarik secara teknis, tim menulis user stories untuk tetap terhubung dengan orang-orang yang mereka bangunkan. Story itu sendiri pendek secara desain. Nilainya berasal dari percakapan yang dipicunya antara product owners, developer, dan pemangku kepentingan.

Fakta Utama

  • User stories dipopulerkan oleh Kent Beck sebagai bagian dari Extreme Programming (XP) pada akhir 1990-an, kemudian diformalkan dalam buku Mike Cohn tahun 2004 User Stories Applied.
  • Menurut State of Agile Report ke-17 (Digital.ai, 2023), 83% tim agile menggunakan user stories sebagai format utama untuk menangkap persyaratan.
  • Tim yang menggunakan kriteria penerimaan yang terstruktur dengan baik bersama user stories melaporkan 40% lebih sedikit cacat dalam tinjauan Sprint, menurut survei praktisi Scrum Alliance 2022.

Template User Story

Template user story: As a role, I want a goal, so that a benefit

Format user story klasik memiliki tiga bagian. Anda akan menemukannya di mana-mana:

As a [role], I want [goal], so that [benefit].

Setiap bagian melakukan pekerjaan spesifik.

Bagian Yang ditangkapnya Contoh
As a [role] Siapa penggunanya? Mengidentifikasi persona atau tipe pengguna yang spesifik. "As a first-time buyer"
I want [goal] Apa yang ingin dilakukan pengguna? Tindakan atau kemampuan yang mereka butuhkan. "I want to save items to a wishlist"
So that [benefit] Mengapa mereka menginginkannya? Outcome atau nilai yang mereka cari. "so that I can come back to them later without searching again"

Disatukan: "As a first-time buyer, I want to save items to a wishlist, so that I can come back to them later without searching again."

Format ini berhasil karena memaksa tim untuk memikirkan tiga hal sekaligus: siapa, apa, dan mengapa. Hilangkan salah satunya dan story menjadi jauh lebih sulit untuk diprioritaskan atau diestimasi. Story tanpa klausa "so that" hanyalah tugas. Itu tidak memberi tahu Anda nilai apa yang Anda ciptakan, yang membuatnya hampir tidak mungkin untuk memutuskan apakah layak dibangun saat perencanaan Sprint.

User Stories vs Epics vs Tugas

User stories berada di tengah hierarki tiga tingkat. Mendapatkan granularitas yang tepat sangat penting ketika Anda menjalankan perencanaan Sprint.

Tingkat Apa itu Granularitas Siapa yang memilikinya Contoh
Epic Sekelompok pekerjaan besar yang dapat dipecah menjadi beberapa stories Luas (minggu hingga bulan) Product Owner "Peningkatan pengalaman belanja"
User Story Satu fitur atau kemampuan dari perspektif pengguna Sedang (1 Sprint atau kurang) Product Owner + Tim "As a buyer, I want to save items to a wishlist..."
Tugas Tindakan teknis spesifik yang diperlukan untuk menghasilkan sebuah story Sempit (jam) Developer "Bangun endpoint API wishlist"

Epics terlalu besar untuk dibangun dalam satu Sprint, sehingga tim memecahnya menjadi user stories. Stories berukuran agar muat dalam satu Sprint. Tugas adalah pekerjaan teknis aktual yang diambil dan dilacak oleh developer di sebuah papan.

Kesalahan umum adalah menulis stories dalam lingkup epic dan kemudian bertanya-tanya mengapa tidak ada yang selesai. Jika sebuah story membutuhkan lebih dari satu Sprint untuk diselesaikan, itu mungkin epic yang menyamar. Pecahlah.

3 Cs dari User Stories

Ron Jeffries memperkenalkan kerangka 3 Cs untuk mendeskripsikan bagaimana user stories benar-benar bekerja dalam praktik. Kartunya hanyalah titik awal.

Card. User story secara tradisional ditulis di kartu indeks fisik (atau setara digitalnya). Kartunya pendek secara desain: satu atau dua kalimat. Ini bukan spesifikasi lengkap. Ini adalah pengingat bahwa sebuah percakapan perlu terjadi.

Conversation. Kartu tersebut memicu diskusi antara product owner, developer, dan sering pemangku kepentingan. Percakapan ini adalah tempat di mana persyaratan aktual dirumuskan. Kartu tidak mengandung semua jawaban. Orang-oranglah yang memilikinya.

Confirmation. Setelah percakapan berlangsung, tim mendokumentasikan kriteria penerimaan: kondisi spesifik yang harus dipenuhi agar story dianggap selesai. Kriteria inilah yang diuji dan diverifikasi sebelum story ditutup.

Sebagian besar tim menulis kartu dan langsung melompat ke coding. Itu terbalik. Langkah percakapan adalah tempat ambiguitas diselesaikan, kasus tepi ditemukan, dan pemahaman bersama dibangun. Stories yang melewati percakapan cenderung kembali untuk pengerjaan ulang.

Kriteria INVEST untuk User Stories yang Baik

Kriteria INVEST untuk user stories yang baik

Bill Wake memperkenalkan akronim INVEST untuk memberi tim daftar periksa kualitas dalam mengevaluasi apakah user story sudah terbentuk dengan baik. Jalankan setiap story melalui daftar ini sebelum menariknya ke dalam Sprint.

Huruf Kriteria Artinya
I Independent Story dapat dibangun dan diselesaikan tanpa bergantung pada story lain yang harus diselesaikan terlebih dahulu.
N Negotiable Story bukan kontrak yang kaku. Detail dapat disesuaikan berdasarkan percakapan dan informasi baru.
V Valuable Story memberikan nilai yang jelas kepada pengguna atau bisnis. Jika Anda tidak bisa mengartikulasikan nilainya, story belum siap.
E Estimable Tim memiliki informasi yang cukup untuk mengestimasi upaya yang diperlukan. Jika mereka tidak bisa mengestimasi, ada sesuatu yang tidak jelas.
S Small Story muat dalam satu Sprint. Jika tidak, pecahlah menjadi stories yang lebih kecil.
T Testable Story memiliki kriteria penerimaan yang dapat diverifikasi. Jika Anda tidak bisa mengujinya, Anda tidak bisa mengonfirmasi bahwa itu selesai.

Lakukan pemeriksaan INVEST cepat selama sesi penyempurnaan Backlog. Jika sebuah story gagal pada kriteria apa pun, jangan tarik ke dalam perencanaan dulu. Perbaiki terlebih dahulu. Kegagalan paling umum adalah "Tidak cukup kecil" (seharusnya epic) dan "Tidak dapat diuji" (belum ada kriteria penerimaan yang ditulis).

Cara Menulis User Story

Menulis user story yang baik membutuhkan lebih dari sekadar mengisi template. Berikut adalah proses yang bekerja secara andal.

Langkah 1: Identifikasi persona pengguna Anda

Siapa yang benar-benar akan menggunakan fitur ini? Jadilah spesifik. "Pengguna" bukanlah persona. "Pengguna baru yang belum mengatur pembayaran" adalah. Semakin konkret personanya, semakin mudah untuk menulis story yang benar-benar mencerminkan kebutuhan mereka.

Jika Anda belum memiliki persona formal, percakapan singkat dengan tim dukungan pelanggan Anda akan mengungkap tipe pengguna yang paling umum dalam waktu sekitar 20 menit.

Langkah 2: Namai tujuannya

Apa yang coba dicapai oleh pengguna? Tuliskan sebagai tindakan: "saring hasil pencarian berdasarkan harga," "ekspor data sebagai file CSV," "terima email konfirmasi setelah checkout." Batasi satu tujuan per story. Jika Anda mendapati diri menulis "dan" dalam tujuan, Anda mungkin memiliki dua stories.

Langkah 3: Nyatakan manfaatnya

Mengapa pengguna menginginkan ini? Outcome apa yang mereka cari? Ini adalah klausa "so that." Ini juga bagian yang paling sering dilewati. Jangan lewati. Manfaat memberi tahu tim seperti apa keberhasilan itu, yang penting ketika trade-off muncul selama pengembangan.

Langkah 4: Tambahkan kriteria penerimaan

Tuliskan kondisi yang harus dipenuhi fitur untuk dianggap selesai. Gunakan bahasa sederhana atau format Given/When/Then (lebih lanjut di bawah ini). Kriteria penerimaan bukan pilihan. Tanpanya, setiap developer di tim memiliki model mental yang sedikit berbeda tentang apa artinya "selesai."

Langkah 5: Estimasi story

Kerjakan dengan tim untuk ukuran story menggunakan story points atau metode estimasi relatif serupa. Jika estimasinya tinggi (biasanya di atas 8 atau 13 pada skala Fibonacci), story kemungkinan terlalu besar. Pecahlah menjadi bagian yang lebih kecil sebelum perencanaan Sprint.

Langkah 6: Prioritaskan dan sempurnakan

Tambahkan story ke Product Backlog dan urutkan berdasarkan nilai. Selama sesi penyempurnaan Backlog, tinjau kembali stories yang akan datang di Sprint berikutnya untuk memastikan mereka masih relevan, berukuran tepat, dan memiliki kriteria penerimaan yang jelas. Stories yang belum disempurnakan baru-baru ini sering membutuhkan pembaruan sebelum siap untuk Sprint.

Contoh User Stories

Berikut adalah contoh konkret di tiga jenis produk yang umum. Masing-masing mengikuti template standar dan mencakup catatan penerimaan singkat.

Jenis produk User story Catatan penerimaan
E-commerce "As a returning customer, I want to reorder a previous purchase in one click, so that I don't have to find each item again manually." Keranjang sudah terisi dengan item pesanan sebelumnya dengan harga saat ini; pengguna mengkonfirmasi sebelum checkout.
SaaS (B2B) "As a team manager, I want to export my team's activity report as a CSV, so that I can share it with my director in a format they can use." Ekspor mencakup filter rentang tanggal, semua kolom yang terlihat di aplikasi, dan diunduh dalam 5 detik untuk hingga 1.000 baris.
Alat internal "As a support agent, I want to see a customer's full ticket history in one view, so that I don't have to switch between systems during a call." Riwayat menampilkan 12 bulan terakhir, diurutkan berdasarkan tanggal terbaru, dengan status tiket dan catatan resolusi terlihat.
Aplikasi mobile "As a new user, I want to complete onboarding in under 3 minutes, so that I can start using the app before I lose interest." Alur Onboarding maksimal 5 layar, dapat dilewati di setiap langkah, dan tidak memerlukan kartu kredit.
Platform analitik "As a marketing analyst, I want to filter dashboard metrics by campaign, so that I can compare performance without switching views." Filter diterapkan secara instan (di bawah 1 detik), mendukung pemilihan beberapa kampanye, dan tetap aktif di seluruh sesi.

Perhatikan bahwa setiap story menamai tipe pengguna yang spesifik, bukan "pengguna" generik. Dan setiap klausa manfaat menjelaskan motivasi nyata, bukan sekadar pernyataan ulang tujuan.

Kriteria Penerimaan dan Definition of Done

Kriteria penerimaan adalah kondisi spesifik yang harus dipenuhi sebuah fitur agar tim menganggap user story selesai. Ini ditulis sebelum pengembangan dimulai, biasanya selama langkah percakapan.

Format yang paling umum adalah Given/When/Then (juga disebut sintaks Gherkin):

  • Given konteks awal atau prasyarat tertentu
  • When pengguna mengambil tindakan tertentu
  • Then outcome tertentu terjadi

Contoh untuk story wishlist:

Given pembeli yang sudah masuk sedang melihat halaman produk
When mereka mengklik tombol "Save to Wishlist"
Then item ditambahkan ke wishlist mereka dan notifikasi konfirmasi muncul; tombol berubah menjadi "Saved"

Definition of Done (DoD) berbeda dari kriteria penerimaan. Kriteria penerimaan spesifik untuk satu story. DoD adalah standar seluruh tim yang berlaku untuk setiap story: unit test ditulis, kode ditinjau, di-deploy ke staging, tidak ada bug kritis. Keduanya harus dipenuhi sebelum story ditutup.

Jangan bingungkan keduanya. Sebuah story dapat memenuhi semua kriteria penerimaannya namun tetap tidak memenuhi DoD jika, misalnya, tidak ada tinjauan kode yang dilakukan. Lacak keduanya.

Kesalahan Umum Saat Menulis User Stories

Menulis dari perspektif sistem, bukan perspektif pengguna. "Sistem harus mengirim email" adalah persyaratan teknis, bukan user story. Tulis ulang: "As a new user, I want to receive a welcome email after signing up, so that I know my account was created successfully."

Melewati klausa manfaat. "As a user, I want to filter results" hampir tidak memberi tim informasi apa pun tentang prioritas atau nilai. Mengapa pengguna ingin menyaring? Keputusan apa yang akan mereka buat dengan hasil yang tersaring? Klausa "so that" adalah tempat informasi nyata berada.

Menulis epics dan menyebutnya stories. "As a user, I want a complete checkout experience" bukan sebuah story. Itu adalah area fitur. Pecahlah menjadi bagian yang spesifik dan dapat diestimasi: pemilihan metode pembayaran, konfirmasi pesanan, email struk, dan sebagainya.

Tidak ada kriteria penerimaan sebelum pengembangan dimulai. Stories tanpa kriteria penerimaan adalah undangan terbuka untuk pengerjaan ulang. Developer menginterpretasikan ambiguitas dengan cara apa yang paling mudah dibangun, bukan selalu yang dimaksud product owner. Tulis kriteria sebelum Sprint dimulai.

Terlalu banyak stories untuk satu Sprint. Tim agile terkadang memuat Backlog dengan lebih banyak stories daripada yang dapat diselesaikan tim secara realistis. Ini menghasilkan pekerjaan yang setengah selesai dan "burndown chart" yang membengkak yang tidak pernah mencapai nol. Gunakan story points dan Velocity historis untuk menetapkan kapasitas Sprint yang realistis.

Mengabaikan langkah prioritisasi MoSCoW. Tidak semua user stories memiliki bobot yang sama. Beberapa adalah keharusan, lainnya bagus untuk dimiliki. Tanpa prioritisasi eksplisit, tim menghabiskan waktu Sprint untuk stories bernilai rendah sementara pekerjaan bernilai tinggi menunggu.

Pertanyaan yang Sering Diajukan

Apa itu user story dalam agile?

User story adalah deskripsi singkat dan sederhana tentang sebuah fitur dari perspektif pengguna, ditulis dalam format "As a [role], I want [goal], so that [benefit]." Ini digunakan dalam tim agile untuk menangkap persyaratan dengan cara yang menjaga fokus pada nilai pengguna daripada spesifikasi teknis. User stories biasanya disimpan dalam Product Backlog dan ditarik ke dalam Sprint berdasarkan prioritas.

Apa perbedaan antara user story dan epic?

Epic adalah sekelompok pekerjaan besar yang terlalu besar untuk diselesaikan dalam satu Sprint. User story adalah irisan yang lebih kecil dan dapat dikirimkan dari pekerjaan tersebut. Epics dipecah menjadi user stories. Misalnya, "Pengalaman checkout" adalah epic. "As a buyer, I want to save my payment details for future purchases" adalah satu user story di dalamnya.

Siapa yang menulis user stories?

Product owner biasanya menulis atau memiliki user stories, namun user stories terbaik berasal dari kolaborasi. Product owners membawa perspektif bisnis dan pengguna. Developer membawa konteks teknis. Desainer UX membawa riset pengguna. Sesi penyempurnaan Backlog adalah tempat perspektif-perspektif ini bergabung untuk menghasilkan stories yang terbentuk dengan baik dan dapat diestimasi.

Apa itu story points?

Story points adalah unit estimasi relatif yang digunakan tim untuk menentukan ukuran user stories. Alih-alih mengestimasi dalam jam (yang bervariasi per orang dan sering tidak akurat), tim membandingkan stories satu sama lain menggunakan skala seperti Fibonacci (1, 2, 3, 5, 8, 13). Story senilai 5 poin kira-kira dua kali lebih kompleks dari story 2 poin. Seiring waktu, tim mengembangkan Velocity yang stabil (poin per Sprint), yang membuat perencanaan Sprint lebih dapat diprediksi.

Apa kepanjangan INVEST dalam user stories?

INVEST adalah daftar periksa kualitas untuk user stories: Independent (dapat dibangun tanpa bergantung pada story lain), Negotiable (detail dapat berubah berdasarkan percakapan), Valuable (memberikan nilai yang jelas kepada pengguna), Estimable (tim dapat menentukan ukurannya), Small (muat dalam satu Sprint), dan Testable (memiliki kriteria penerimaan yang dapat diverifikasi). Jika story gagal pada salah satunya, story belum siap untuk Sprint.

User stories yang baik tidak menulis sendiri. Namun tim yang meluangkan waktu untuk menulisnya dengan benar: menamai persona pengguna nyata, menulis klausa manfaat yang jelas, dan melampirkan kriteria penerimaan yang dapat diuji sebelum pengembangan dimulai, menghabiskan lebih sedikit waktu untuk pengerjaan ulang dan lebih banyak waktu untuk mengirimkan hal-hal yang penting.

Mulailah dengan satu story untuk item Backlog prioritas tertinggi Anda saat ini. Terapkan template, jalankan pemeriksaan INVEST, dan tulis dua atau tiga kriteria penerimaan. Itulah kebiasaannya. Bangun dari sana.

Untuk kerangka terkait, lihat struktur rincian kerja untuk mengurai ruang lingkup proyek, perencanaan Sprint untuk menarik stories ke dalam Sprint, dan scrum vs kanban jika Anda memutuskan alur kerja mana yang paling cocok untuk tim Anda.